In many cases it is helpful to ensure that this transition was done properly and [...]]]> During an OCS to Lync migration, existing OCS user settings, including user policies, are transitioned to Lync when the OCS pool is merged into the Lync deployment and OCS users are migrated from their home OCS pool to the Lync pool.

In many cases it is helpful to ensure that this transition was done properly and users have equivalent Lync functionality to what they had in OCS after the migration. But how do you verify this once the users have already been migrated over?

Answer: do a quick backup of your OCS user settings before you migrate your users. This gives you the ability to make sure that a user who was enabled for Public Instant Messaging for example (aka PIC) is also enabled for PIC after the user account has been migrated to Lync.

Below is small VBScript that you can customize to backup the existing OCS user settings. The script enumerates through all OCS enabled users and makes use of the OCS WMI MSFT_SIPESUserSetting class to access their current OCS settings, and outputs it to a file called called OCSUsers.txt:

Set objFSO = CreateObject(”Scripting.FileSystemObject”)
Set objFile = objFSO.CreateTextFile(”OCSusers.txt”, True)

objFile.WriteLine “Starting…”

strComputer = “.”

Set objWMIService = GetObject(”winmgmts:” _
& “{impersonationLevel=impersonate}!\\” _
& strComputer & “\root\cimv2″)

Set colSoftware = objWMIService.ExecQuery(”select * from MSFT_SIPESUserSetting”)

For Each objItem in colSoftware
objFile.WriteLine “OCS User Name: ” & objItem.DisplayName
objFile.WriteLine “PrimaryURI: ” & objItem.primaryURI
objFile.WriteLine “Enabled for Enhanced Presence: “  & objItem.EnabledForEnhancedPresence
objFile.WriteLine “Remote Access: “  & objItem.EnabledForInternetAccess
objFile.WriteLine “Federation: “  & objItem.EnabledForFederation
objFile.WriteLine “Public IM: “  & objItem.PublicNetworkEnabled

objFile.WriteLine “Location Profile: “  & objItem.LocationProfile
objFile.WriteLine “Meeting Policy: “  & objItem.MeetingPolicy

objFile.WriteLine “—————————————————-”
Next

Customize the script to include whatever OCS user settings are important in your environment by adding a objFile.WriteLine line with an OCS user property from the WMI MSFT_SIPESUserSetting class. All the user properties are available here: http://msdn.microsoft.com/en-us/library/dd167418(v=office.13).aspx.

Save the above script to a *.vbs file (e.g. OCSUsers.vbs).  To execute it, just type the script name on a command line in a regular cmd window.

Note: if the OCS user policy value is blank for a user, the setting is to use the default Global policy setting.

While a script like this is good for a one-time verification, if you have larger user inventory and usage reporting needs, there are 3rd-party products such as Quest MessageStats which provide these types of reports for both OCS and Lync.

For more information on OCS to Lync migrations, see:

1. Migration from Office Communications Server 2007 R2 to Lync Server 2010: http://technet.microsoft.com/en-us/library/gg413057.aspx
2. Lync & OCS Migration Top 10: http://blog.insideocs.com/2011/01/11/lync-ocs-migration-top-10/

The NextHop write-up does a good job detailing all the issues that are addressed: Office Communications Server 2007 R2 Updates Now Available: April 2012.

The two noteworthy updates from my perspective are:

Specifically you now have the option of querying the locally configured DNS server for the following [...]]]> A quick post to let followers of my Remote UC Troubleshooting Tool (RUCT) for Lync and OCS know that the DNS records used by the Lync mobility clients to auto-discover the Lync mobility service have been added.

Specifically you now have the option of querying the locally configured DNS server for the following records:

• Lyncdiscover.<domain.com>   (both CNAME or A record)
• Lyncdiscoverinternal.<domain.com>  (both CNAME or A record)

From the same screen you can ping the resulting hostname or test the port availability on any of the Lync DNS record matches.

Here is a sample screen shot with the Lync Auto-Discovery Mobility DNS record:

See http://blog.insideocs.com/2011/11/14/the-remote-uc-troubleshooting-tool-ruct/ for more information on this free Windows tool.

More information about the Lync Mobility DNS records can be found here:

• Lync 2010 Mobility – Do I need lyncdiscoverinternal?
• Lync Mobility, lyncdiscoverinternal or lyncdiscover
• Microsoft TechNet – Technical Requirements for Mobility
• Microsoft Lync 2010 for the iPhone and iPad Released

If you have previously established direct federation connections between OCS and many federated partners that you explicitly allow, the thought of having to manually re-enter these federation settings [...]]]> During the edge migration stage of an OCS to Lync migration, you will likely need to re-establish existing OCS federated partner settings on the new Lync Edge pool.

If you have previously established direct federation connections between OCS and many federated partners that you explicitly allow, the thought of having to manually re-enter these federation settings in Lync isn’t very appealing.

Whenever a lot of manual administration is required, PowerShell comes to mind. Indeed, in this case it can be used to ease the pain of having to manually retype the federated partner domain, and optionally, the associated edge server FQDN.

In this post I provide a small PowerShell script that you can run on your OCS 2007 R2 Edge server that can be used to export your existing federated partner settings in the format of another PowerShell script that can be run to re-import those settings into Lync.

Caveat – your existing OCS partner federation settings could differ slightly. It is important to understand what this script is doing (it is straightforward) and tweak it to your configuration.

The following script runs on the OCS 2007 R2 edge and utilizes WMI – specifically the OCS 2007 R2 MSFT_SIPFederationPartnerTable class – to export a list of the federated partner domains:

Get-WmiObject -class MSFT_SIPFederationPartnerTable | ForEach-Object

{

   $domain = [System.String]$_.Domain

   $edgeProxy = [System.String]$_.EdgeProxyAddress

   if ($edgeProxy -eq "")

   {

      write-output "New-CsAllowedDomain -Identity `"$domain`" -MarkForMonitoring `$True"

   }

   else

   {

       write-output "New-CsAllowedDomain -Identity `"$domain`" -ProxyFqdn `"$edgeProxy`" -MarkForMonitoring `$True"

   }

}

Save the above script to a PowerShell .ps1 file (e.g. EdgeFed.ps1). To run it in Powershell you will likely first need to set the ExecutionPolicy to allow scripts to run:

> Set-ExecutionPolicy Unrestricted

Invoking this script on the OCS Edge server (e.g. run “.\EdgeFed.ps1” in a PowerShell command window) will produce output similar to the following:

New-CsAllowedDomain -Identity "contoso.com" -MarkForMonitoring $True

New-CsAllowedDomain -Identity "fabrikam.com" -ProxyFqdn "im.fabrikam.com" -MarkForMonitoring $True

.

.

The script exports each federated partner setting and formats it into a Lync PowerShell “New-CsAllowedDomain” cmdlet which will add the partner as a new allowed federated domain in Lync.

Pipe the output of this script to another .ps1 file that can used on your Lync Edge (i.e. run “.\EdgeFed.ps1 > LyncFedSettings.ps1”).

To import the allowed federated partners into Lync, put the output file (e.g. LyncFedSettings.ps1) on your Lync Front-End or Edge server and run it in the Lync Management Shell.

You can see the new federated partner allow list with the Get-CsAllowedDomain cmdlet, or in the Lync Control Panel (External User Access | Federated Domains).

If your OCS federated partner settings differ from the explicit allow list method, and you need an automated solution, take a look at the WMI Classes for Office Communications Server. There is probably a WMI class that exposes these settings and can be scripted, and you can just modify the script above.

Addition OCS to Lync Migration Articles

• Microsoft TechNet – Migration from Office Communications Server 2007 R2 to Lync Server 2010
• InsideOCS – Lync & OCS Migration Top 10
• InsideOCS – Quick Tip – External Contacts with Lync Coexistence

Everything worked as planned except the [...]]]> I was involved in a recent Lync migration where a new Lync pool was deployed side-by-side with an OCS 2007 R2 pool. Several pilot users were moved to the new Lync pool and the OCS 2007 R2 edge server was still being used for external Lync and OCS user services.

Everything worked as planned except the Lync users on the new Lync pool were getting the infamous “Presence Unknown” for both Public IM (PIC) contacts and their Federated Contacts.

All the basics were checked – connectivity between the new Lync pool and the OCS 2007 R2 edge, certificates, etc…, and everything looked okay.

What solved the problem in the end was rebooting the OCS 2007 R2 edge server.  After the OCS edge server was rebooted, all of the PIC and Federated contacts for the new Lync pool users started to work.  I am not sure exactly what effect rebooting the edge had, but wanted to pass it along in case it helped someone else.