A CU has been released for the Resource Kit that should be installed on all Lync 2010 servers where the Resource Kit is installed. The update and link to the KB2672435 are found in the table below.
|
Product |
KB Link |
Download |
|
|
Lync 2010 Resource Kit |
|||
0 comments - Posted by Brian Ricks at 4:49 AM - Categories: 2010 | Resource Kit | Update | Lync Server
The second week of videos are now up on TechNet Edge and have been grouped together and linked for your reading pleasure here on Microsoft NextHop. During the second week I spent time with Rui Maximo discussing the Architect's role in working with the business, gathering requirements, and designing a solution. Check it out and let me know what you think.
0 comments - Posted by Brian Ricks at 4:12 PM - Categories: 2010 | BriComp | JumpStart | Lync Server | Rui Maximo
For two weeks this month I spent my days and evening is Redmond, WA assisting Microsoft Learning with recording two Lync Server series. These series - 18 courses each - are available for view or download from the Microsoft TechNet Edge. NextHop has done us the favor of creating a master link page for the first series which is found here.
If you are interested in some Lync Server 2010 training or want to prepare for the Microsoft Lync exams, check the series out. The second series - design - will be coming soon!
0 comments - Posted by Brian Ricks at 10:32 AM - Categories: 2010 | Aaron Steele | JumpStart | Lync Server
Last week Microsoft quietly released CU5 for Lync 2010. The list of the various updates may be found below and the update includes a patch for mobility (if mobility is configured and deployed). I have installed the updates without any issue although the pool servers did require a reboot.
UPDATE: Lync Client and Server patches have been updated March 29th - the links below reflect the most current updates.
|
Product |
KB Link |
Download |
|
|
Lync 2010 (64bit) |
|||
|
Lync 2010 (32bit) |
|||
|
Lync Sever 2010 |
|||
|
Lync 2010 Phone Edition (Tanjay) |
|||
|
Lync 2010 Phone Edition (Aries-Aastra) |
|||
|
Lync 2010 Phone Edition (Aries-Polycom) |
|||
|
Lync 2010 Phone Edition (Hewlett-Packard) |
|||
|
Lync 2010 Attendee (Admin Install) |
|||
|
Lync 2010 Attendee (User mode install) |
|||
|
Lync 2010 Attendant (32 & 64 bit are a combined patch) |
|||
|
Lync 2010 Group Chat Client |
|||
|
Lync 2010 Group Chat Server |
|||
|
Lync 2010 Group Chat Admin |
|||
Additional Notes:
Lync Server 2010 build number is 4.0.7577.197
Lync Client build number is 4.0.7577.4087
Lync Group Chat build number is 4.0.7577.4071
Lync Attendee build number is 4.0.7577.254
Lync Attendant build number is 4.0.7577.253
Lync Phone Editions build number is 4.0.7577.4066
0 comments - Posted by Brian Ricks at 7:02 AM - Categories: 2010 | CU5 | Group Chat | Lync | Lync Phone Edition | Lync Server
I recently received the opportunity to setup and use a F5 BIG-IP LTM Hardware Load Balancer version 11.1 and have since configured it for Lync Web Services including Mobility. The configuration does not have to be complex, and while the Load Balancer does much more than I am demonstrating here, incorporating the changes below into your own configuration should prove successful.
The example I am showing below is based on version 11.1 of the LB code. If you are using an older version (and at some point a newer version) the exact screenshots and options may be slightly different - but the concepts remain the same. Like my setup and configuration of my KEMP HLB, I have opted to use two VIPs so that I can pass internal traffic directly back to the external pool rather than hair-pinning through a Reverse Proxy.
Because I am using two VIPs the setup and configuration concept which was used in the KEMP setup remains the same. The configuration once again would look something like this:
Internal Web Services VIP
10.10.10.10:443 --> 10.10.10.50:443
10.10.10.10:80 --> 10.10.10.50:80
External Web Services VIP
10.10.10.20:443 --> 10.10.10.50:4443
10.10.10.20:80 --> 10.10.10.50:8080
With this configuration, the port address translation happens on the HLB so the Reverse Proxy or Firewall can send the external traffic unchanged. Internally, the communication is always bound for HTTP/HTTPS and then changed depending on the destination IP.
I have already expressed the Data Flow in previous posts, so suffice it say I am not changing those concepts at all - inbound/outbound traffic comes in on 80/443 and the Load Balancer (based of the VIP) determines if it goes to 80/443 or 8080/4443. Because the port address translation happens on the VIP of the Load balancer when needed, the hair-pinning back to the Reverse Proxy is unnecessary. That also means when deploying the RP, make sure you do not change the ports.
Configuration of the Load Balancer includes the initial setup (not addressed here), the importing of the External Web Services certificate (required for Cookies), Configuring Profiles and Virtual Servers (including Pools and Nodes).
There are multiple places to start, but the Certificate is as good as any. If this is not correct, iOS machines will fail to connect and Android and WP7 will take longer to authenticate. To start, and assuming the external web services certificate is marked as exportable (it should be if defaults were accepted), navigate to one of the Lync 2010 FE servers and launch the MMC (Start | Run | mmc). Add the local Computer Certificate Store to access your certificates (File | Add/Remove Snap-in | Certificates).
Expand Certificate | Personal | Certificates and in the right select your external certificate. Right-click the certificate and select All Tasks | Export. This will launch the Certificate Export Wizard. Select Yes, export the private key and select Next.
In the export options select Include all Certificates in the certification path if possible and Export all extended properties. This will include the root chain in the certificate path preventing trust issues on the BIG-IP.
Enter and confirm a password when prompted (you need this password to import the private key), select a file location and name, and click Finish.
Copy the exported file to a location you have access to from you local web browser. Launch the BIG-IP web configuration page, expand Local Traffic | SSL Certificate List. In the upper-right select Import to launch the import process. The correct import type is PKCS 12 (IIS) and should be selected from the drop-down menu. Enter a name for to reference the certificate, browse to the previously exported certificate PFX file and enter the password created when the certificate was exported. Click Import to bring the certificate into the BIG-IP.
You will see the certificate in the SSL Certificate List and if you select the certificate name, you will see not only your Web Services certificate but the entire certificate chain in the Certificate Subject(s) field.
Now that the certificate has been imported, the cookie persistence may be created. Back in the BIG-IP web interface, select Local Traffic | Virtual Servers | Profiles | Persistence. Two persistence profiles will be created - one for the external web services and one for the internal web services. In the upper-right select Create to being the profile creation process. Enter a name for the Profile, and select Cookie for the Persistence Type. Under Configuration, mark the Custom box to allow configuration of the various properties. Match the settings to the picture setting the cookie name to MS-WSMAN, always send cookie, and set the expiration to 3 days. Click Repeat to create the persistence profile and start the process over.
Next create a new Source-Based persistence profile. Enter a name for the profile, and select Source Address Affinity for the Persistence Type. Under configuration, mark the Custom box to allow configuration of the properties. Match the settings to the picture below setting the timeout to 1800 seconds and click Finished to create the second custom persistence profile.
Next we move onto the SSL Profile. The SSL profile specifies which certificate to present to incoming connections. There are two types of SSL profiles, Client and Server. For Lync we need to worry about the Client certificate and will create a new profile based of the clientssl profile. Select Local Traffic | Virtual Servers | Profiles | SSL | Client. In the upper right select Create to begin the profile creation process. Enter a name and make sure clientssl is selected as the parent profile. Under configuration, mark the Custom box to allow configuration of the properties. Match the settings to the picture below setting the certificate and key to the name previously setup and created when the SSL Certificate was imported. Click Finished creating the new profile.
The Nodes selection under Local Traffic specifies which real servers will be participating in the pool. Select Local Traffic | Virtual Servers | Nodes | Node List. Just as in previous steps, we are going to click Create to start the process. Enter a name (typically the server name but whatever you want) and the IP address under Address. The base health monitor is for the server and may be individually configured here or simply use the default. Click Repeat to add the additional nodes in the same manner. When the last node has been created, click Finished.
To configure the default node monitor, select Local Traffic | Virtual Servers | Nodes | Default Monitor. Select ICMP and click the << to add it to the list. This monitor will do a simple PING up/down test to validate the server is running. We will create an optional monitor for the pool members to validate the services are running.
The Lync Monitor port verifies the Lync Front-End service is running. While the server may be running, if the pool is not up and functioning it really does not help us. In addition, it is important IIS is up and functioning; we can use the built-in monitors for the internal websites but must create new ones for the external websites.
Start by navigating to Local Traffic | Monitors. Click Create to start the process; we will begin with the Pool Monitor. Enter a name for the monitor and select TCP from the Type drop-down. We will need to change the Configuration from Basic to Advanced to expose the port. The port is located at the bottom of the list and is represented by default with an asterisk. Update the aterisk to the custom port you would have already configured in the Lync Topology Builder. In my case I have set it to 5150 but this is whatever your Pool is set to.
Click Repeat to save the monitor and start the process over. Enter a name for the External SSL (port 4443) monitor and select HTTPS as the Type. Advanced Configuration should already be exposed; just like the Pool monitor at the bottom of the options is the port. Here enter 4443 and click Repeat.
The last monitor we will create is for port 8080, the External Web Services re-direct port. Enter a name for the External (port 8080) monitor and select HTTP as the Type. Advanced Configuration should already be exposed; just like the Pool monitor at the bottom of the options is the port. Here enter 8080 and click Finished.
Pools represent the collection of services that will be tied to a Virtual Server (and its corresponding VIP). We will be creating four pools - Internal 80, 443 and External 8080, 4443.
Start by selecting Local Traffic | Virtual Servers | Pools | Pool List. Click Create to start begin - we will start with the Internal Web Services 443. Enter a Name for the Pool. Select the Lync Pool Monitor previously created and click << to add it to the list. Scroll down the monitor list and select https_443 and once again select <<. Change the Load Balancing Method to Least Connections (member) and click Node List. The various nodes already created will be listed. Select the first node, enter 443 for the service port, and click Add. Repeat for the remaining nodes. Once all the nodes are listed click Repeat to continue the process.
Create the three additional pools, one for Internal 80, one for External 4443, and one for External 8080 replacing only the service ports and the monitors per the pictures below (make sure to Click Repeat until the final pool to speed up the process and remove and re-add the members to get the new port definition).
The final step in the process is the creation of the Virtual Servers. The Virtual Servers tie the pools to a Virtual IP (VIP) and expose the desired port. There will be two VIPs two per pool (internal and external). Navigate to Local Traffic | Virtual Servers | Virtual Server List to begin.
Click Create to define the Virtual Server and VIP. Start by entering a name and entering the VIP address in Name and Destination. We will start with the Internal 443 SSL VS. In the service port enter 443. On the internal SSL web site we will be using IP source-based persistence so there is no need to decrypt the information - we simply want to pass traffic. Configure the settings as shown below making sure that no HTTP or SSL profile is selected and SNAT Pool is set to Auto Map. Change the Default pool to your Internal 443 Pool previously created, set your Default Persistence to your Internal Source IP Persistence profile also previously created and click Repeat.
Three additional Virtual Servers will need to be created as shown below. Make sure the Pools are correct as well as the Persistence. When creating the External 4443 Virtual Server you will need to select the basic HTTP Profile and the previously create SSL Profile. The configuration is shown below.
Click Finished after the last Virtual Server has been created. The final steps are to simply update DNS to point the various A and CNAME records of MEET, DIALIN, INTERNALMEETINGS, and EXTERALMEETINGS VIPs.
0 comments - Posted by Brian Ricks at 10:18 AM - Categories: 2010 | BIG-IP | F5 | Lync Server
Like many I was excited to see the mobility client finally released for Lync 2010 but needed to figure out what communication was going where - can't fix what you do not understand.
When using mobility, internally or externally, all communication flows from the mobile device to the External Web Services of your pool. The concept is that there is a single point of communication regardless of your network allowing communication to seamlessly move network to network. In order to achieve this, the external services URLs must be reachable internally when a client access port 443.
That requirement was not as daunting as one might think when using a Hardware Load Balancer, in this case it was my KEMP. The key on the KEMP was to have two VIPs created, one for internal communication and one for external communication. The configuration looked something like this:
Internal Web Services VIP
10.10.10.10:443 --> 10.10.10.50:443
10.10.10.10:80 --> 10.10.10.50:80
External Web Services VIP
10.10.10.20:443 --> 10.10.10.50:4443
10.10.10.20:80 --> 10.10.10.50:8080
With this configuration, the port address translation happens on the HLB so the Reverse Proxy or Firewall can send the external traffic unchanged. Internally, the communication is always bound for HTTP/HTTPS and then changed depending on the destination IP.
Looking at communication from a phone via cellular and WiFi then looks like so:
Cellular
Phone IP (12.5.5.23) --> Ext AutoDiscover (68.5.12.54:443) --> Ext Web Services URL (68.5.12.54:443) --> HLB (10.10.10.20:443) --> Lync Pool External Web Services (10.10.10.50:4443)
WiFi
Phone IP (10.10.10.100) --> Internal AutoDiscover (10.10.10.10:443) --> Int Web Services (10.10.10.10:443) --> Ext Web Services URL/HLB (10.10.10.20:443) --> Lync Pool External Web Services (10.10.10.50:4443)
As you can see both methods end up going to the external web services which is managed by the KEMP HLB. The only difference is when on the internal WiFi it is able to resolve the internal pool which passes the Mobile URL information back which is the external web services URL. Because the external web services URL resolves internally to the VIP created for the external web services, it is redirected to port 4443.
That sets the data flow as we want, now the only thing left is the configuration of the KEMP HLB which requires the setup using cookies for persistence (again referencing Dave Howe's article here).
The KEMP configuration for Lync is fairly easy with the setting below. You will need your external certificate so that is can be loaded into the HLB (public and private key) as it will need to decrypt and re-encrypt the communication. An example configuration would be:
Basic Properties
Service Type: HTTP/HTTPS
L7 Transparency: Disabled
Real Server Check Parameters: Optional but recommended
Service Nickname: Lync Web Servers -4443
Persistence Options
Mode: Active Cookie
Timeout: 3 Days (the length of an inactive Push Session before it times out)
Cookie Name: MS-WSMAN
Scheduling Method: resource based (adaptive)
Idle Connection Timeout: 0
Use Address for SNAT: Unchecked
SSL Properties
SSL Acceleration: Enabled and Reencrypt checked
Certificates: Load the external web services certificate here
Rewrite rules: None
Client Certificates: No Client Certificates required
Advanced Properties
Content Switching: Disabled
HTTP Headre Modifications: None
Port Following: No Port Selected
Enable Caching: Unchecked
Enable Compression: Unchecked
Detect Malicious Requests: Unchecked
Add Header to Request:
Not Available Server:
Not Available Redirection Handling:
Default Gateway:
Assuming there are physical servers that the VIP is pointing to (again redirecting to port 4443 and 8080) communication should now flow. As key a reminder, make sure the external web services URL resolves internally to the external HLB VIP configured above and you are good.
4 comments - Posted by Brian Ricks at 7:51 AM - Categories: 2010 | mobile | KEMP HLB | Lync | Lync Server
The mobility features of Lync have been sorely missed since Lync 2010 was release last November but Microsoft has made HUGE strides in their recent release. There are a few pre-requisites which we will cover as well as some gotchas to look out for. As of today the Windows Phone client (Mango required) is available in the Marketplace but the Apple iOS and Android clients have yet to appear. There should also be a Nokia client but I do not have a method to test so unfortunately I have nothing to report there.
Before mobility can be configured the current Lync environment requires CU4 to already be installed. If this has not been done, first things first. There are also a few configuration requirements that must be met which while it didn't matter without mobility, now it does. Those include:
Once that is complete there is a mobility download that must be grabbed and server-based PowerShell commands that are run on a Front-End Server in the environment. The configuration includes updating DNS, requesting and installing new certificates, configuring ports etc. so let's begin.
The first task completed when configuring mobility is running two PowerShell commands to configure the ports mobility will use inside and outside. Setting the ports will also 'inform; the bootstrapper process that mobility should be installed and configured. To set your ports simply launch Lync Server Management Shell (LSMS) and type:
Set-CsWebServer –Identity lspoolname.domain.com –McxSipPrimaryListeningPort 5086
Set-CsWebServer –Identity lspoolname.domain.com –McxSipExternalListeningPort 5087
Enable-CsTopology
You can see the internal listening port has been set at 5086 with the external ports set to 5087. The enable command sets the changes into the topology and the Lync environment is now aware that mobility should be there. The above two Set-CsWebServer commands with the MCX values will only work if CU4 is installed.
If the IID Dynamic Content Compression was not already added (listed as a pre-requisite above) now is the time to complete the process as without it setup will fail. If your base operating system for your Lync Front-End/Director server is Windows Server 2008, use the following command:
[from a command prompt] ServerManagerCMD.exe –Install Web-Dyn-Compression
If the base operating system for your Lync Front-End/Director server is Windows Server 2008 R2, use the following command:
[from PowerShell] Import-Module ServerManager; Add-WindowsFeature Web-Server, Web-Dyn-Compression
New DNS names have been established for the AutoDiscover process (think Exchange AutoDiscover). The new feature removes the need for you to configure the explicit server settings on the mobile clients (very nice). There are up to three different records that must be created, two of which are on the inside DNS. Two of the three records are CNAME DNS records while the third (required if split-DNS) is an 'A" record.
Internal DNS create CNAME record lyncdiscoverinternal and point it to the internal web services 'A' record
External DNS create CNSME record lyncdiscover and point it to the external web services 'A' record
Internal DNS (if using split-DNS) create 'A' record for your external web services name and configure it to the external IP
The installation of the BITS is completed by downloading the new MSI, placing it in the expected folders, and running bootstrapper.
To begin, download the MSI at Microsoft's download center here. Save the MSI locally to each Front-End and Director server in the path C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup. This is the location of the cached Lync 2010 installers. Once the MSI is in the correct path, launch LSMS and run C:\Program Files\Microsoft Lync Server 2010\Deployment\Bootstrapper.exe (NOTE: the path C:\Program Files\Microsoft Lync Server 2010\ may be different in your deployment based off of where Lync was installed)
Bootstrapper will detect the configuration/setting of the mobility ports and install the mobility BITS on the required servers.
Assuming push notifications are desired on the iOS and Windows Phone platforms, enter the following after the installation is complete (from LSMS):
Set-CsPushNotificationConfiguration -EnableApplePushNotificationService $true -EnableMicrosoftPushNotificationService $true
New-CsHostingProvider –Identity "LyncOnline" –Enabled $True –ProxyFqdn "sipfed.online.lync.com" –VerificationLevel UseSourceVerification
New-CsAllowedDomain –Identity "push.lync.com"
Because there are new names internally and externally new SANs are required on both the internal and external certificates. The simplest way to request a new certificate is using the Lync Deployment application on a Front-End server (one per pool). The server has the ability to create both the internal and external certificates using the GUI. If you are in a multi-server pool I recommend having three separate certificates on the pool - one unique to each Front-End and the other two used on each Front-End (same certificate).
If you already have the Server Default certificate unique to the Front-End server (it will have the pool name, server name, and most likely 'sip'), then the next step is running the wizard again and ONLY selecting Web Services Internal. Running the wizard will include all known names for all supported SIP domains - this includes the internal web services FQDN as the CN and meet, dialin, lyncdiscoverinternal, and your lyncadmin name as SANs. If you use an external certificate provider, that certificate request can be sent off for processing.
Next launch the certificate wizard again this time making sure only Web Services External is selected, offline certificate is selected, and mark as exportable is checked. The results for the external certificate request will be a certificate with the external web services FQDN as the CN and meet, dialin, and lyncdiscover as SANs. Once the certificate has been processed externally you have two options. If you are using a Reverse Proxy where the certificate is required or a HLB, export the certificate from the server and import into the appropriate location. Assuming you are using an internal CA, you would then have the option to re-request an internal certificate for the external web services role. If you are NAT'ing directly to a single server (no HLB but a single point of failure) then you may leave the certificate as is.
Once the configuration is complete, reboot the various servers and validate that there are no unexpected errors in the Lync logs in the Event Viewer. Once the servers are back online, assuming all is well launch LSMS and run the following command (replacing your two test users with appropriate names and accounts):
Test-CsMcxP2PIM -TargetFqdn lspoolname.domain.com -SenderSipAddress sip:user1@domain.com -SenderCredential "domain\user1" -ReceiverSipAddress sip:user2@domain.com -ReceiverCredential "domain\user2"
The result of the test should look like:
TargetUri : https://internalwebservicesname.domain.com:443/mcx
TargetFqdn : lspoolname.domain.com
Result : Success
Latency : 00:00:00
Error :
Diagnosis :
Lync Mobility Installation Guide from Microsoft
Lync Server 2010 Mobility Service MSI Download
Dave Howe's HLB Config Guide for Lync 2010
0 comments - Posted by Brian Ricks at 10:14 AM - Categories: 2010 | Microsoft | mobile | Lync | Lync Server | RTM