One of the steps in creating OAuth integration between Lync Server 2013 and Exchange Server 2013 is to create a New-CsPartnerApplication on Lync 2013 referencing the OAuth metadata document from Exchange 2013 (http://technet.microsoft.com/en-us/library/jj688151.aspx):

New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl "https://autodiscover.litwareinc.com/autodiscover/metadata/json/1"

When running this cmdlet you might get the error "New-CsPartnerApplication: Cannot bind parameter 'MetadataUrl' to the target. Exception setting "MetadataUrl": "The metadata document could not be downloaded from the URL in the MetadataUrl parameter or downloaded data is not a valid metadata document, error: The remote server returned an error: (500) Internal Server Error."

When you look in the IIS log on the CAS server you will see a corresponding entry similar to this "2012-11-20 14:03:57 192.168.200.40 GET /autodiscover/metadata/json/1 - 443 - 192.168.200.35 - 500 0 0 265".

I have seen this in a couple of cases and the common root cause has been that the "Microsoft Exchange Server Auth Certificate" has been missing from Local Computer\Personal certificate store.

The "Microsoft Exchange Server Auth Certificate" certificate is used by the OAuth implementation on Exchange 2013. You can see it referenced in the output of Get-AuthConfig:

Get-AuthConfig

RunspaceId : b7de8683-bd90-4e24-a78f-d6933871cd48

CurrentCertificateThumbprint : A33E4C629AE9553E186F93474E796D598B1F7424

PreviousCertificateThumbprint :

NextCertificateThumbprint :

NextCertificateEffectiveDate :

ServiceName : 00000002-0000-0ff1-ce00-000000000000

Realm :

Name : Auth Configuration

The certificate with CurrentcertificateThumbprint needs to be listed, when you do Get-ExchangeCertificate on the Exchange 2013 servers. If it is not, there you will see the problem with Internal Server Error.

The fix is to create a new "Microsoft Exchange Server Auth Certificate" by using the following sequence of cmdlets In EMS on the MBX server:

1. New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn= Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -Services smtp
   1. Do not accept to replace the SMTP certificate when prompted
2. Note the thumbprint of the new certificate. Let us assume it is 7A39541F8DF58D4821967DD8F899B27410F7C081
3. $a=get-date
4. Set-AuthConfig -NewCertificateThumbprint 7A39541F8DF58D4821967DD8F899B27410F7C081 –NewCertificateEffectiveDate $a
   1. Accept to continue despite the fact that the certificate effective date is not 48 hours into the future
5. Set-AuthConfig –PublishCertificate
6. Make sure to remove any potential reference to the previous certificate (which might not exist anymore) by doing Set-AuthConfig -ClearPreviousCertificate.

Remember to do iisreset on both CAS and MBX servers. Then finally, you can try to re-issue the New-CsPartnerApplication cmdlet.

Update: Jan 15. 2013: Matt reported that he had to add a step, 6) Set-AuthConfig –clearpreviouscertificate, to get it to work in his lab.

Imagine a scenario where Alice is homed on a Lync 2013 server, but has never signed in with the Lync 2013 client. Alice has an Exchange 2013 mailbox and she has loaded a high-resolution photo via Exchange 2013 OWA.

Will other users in the company, using the Lync 2013 client, see Alice's high-resolution photo in peer-to-peer and conference sessions?

No, they will not. The users will see the lower resolution version of the photo from Active Directory.

Why you might ask?

The reason is that Alice has not yet signed in with the Lync 2013 client. As soon as she does it, the Lync 2013 client will see that the high-resolution photo exists for her, and it will update the presence information for Alice to show that she has a high-resolution photo in Exchange 2013. When the other Lync 2013 users sees that presence information update, they will access and display the high-resolution photo for Alice.

This post describes how to configure Exchange 2013 OWA IM Integration to Lync 2013. It mentions that you need to create a trusted application pool and trusted application in the Lync 2013 topology representing the Exchange 2013 MBX server and OWA. Let me try to explain why this is so and when you have to do it.

Internally OCS and Lync uses the concept of Known Servers and it maintain a list of them, the so-called Known Servers Table (KST). A server needs to be in the KST, before Lync will communicate with it. The KST is created from information found in the Lync topology. You can also add to the table by creating Trusted Application Pools from Lync Server Management Shell or from adding Trusted application servers in Lync Server 2013 Topology Builder. A Known Server has a version number attached to it. The version number is related to the Lync version used when creating the known server: 6 is Lync 2013, 5 is Lync 2010 and 0 is any.

When RTCSRV starts, it will log event 14492 from LS Protocol Stack listing all the known servers. It will also log event 14493 from LS Protocol Stack, when a server is added to the KST, and event 14495, when a server is removed from the KST.

When the Exchange UM Integration was introduced with OCS 2007, we wanted to automate the creation of known servers for Exchange UM servers. Consequently, the Exchange UM Routing component adds the Exchange servers it finds to the KST. The servers it finds are the Exchange servers hosting SipName UM Dial Plans. It logs event 44024 from LS Exchange Unified Messaging Routing at startup listing the servers it found. It will also log events while running; indicating added or removed Exchange servers. When adding Exchange servers to the KST it sets the version to 0.

That was the background. Let us look at what happens.

We will assume an environment with Lync 2013 and an Exchange 2013 server called ex1.contoso.com. It is running all Exchange 2013 server roles, is hosting a SipName UM dial plan and Exchange OWA IM Integration has been configured.

When the Exchange UM Routing component starts it will add the entry {fqdn=ex1.contoso.com, version=0} to the KST. At this point Exchange UM integration and Exchange OWA IM Integration to Lync 2013 both works.

The Lync 2013 administrator then adds Trusted Application Pool and Application representing the Exchange server and OWA to the Lync topology. This means adding the entry {fqdn=ex1.contoso.com, version=6} to the KST. However, it is not legal to have two entries for the same server with different versions. The event 14563 from LS Protocol Stack is logged and both entries are removed from the KST.

This has the effect that Exchange UM and OWA IM Integration stops working, since there is no entry for ex1.contoso.com in the KST.

How to get Exchange UM and OWA IM integration working again?

Option 1

Remove the Trusted Application Pool and Application representing the Exchange server and the integration will start working again shortly.

Note: The caveat with using this option is that you have to remember to add the Trusted Application Pool and Application back to Lync 2013, if the Exchange server stop hosting a SipName UM dial plan.

Option 2

Restart RTCSRV on the Lync 2013 server. The restart will still produce the error event 14563 and a warning event 44030, but afterwards you will see an Information event 14493 from LS Protocol Stack adding the Exchange 2013 server to the KST. At this point, the integration works again.

When running The Lync Server 2013 cmdlet Test-CsExStorageConnectivity to test connectivity to Exchange 2013, you might see the error Access Denied as shown below

Test-CsExStorageConnectivity : ExCreateItem exchange operation failed, code=5,

reason=StoreContext{traceId=[18446744072318937492],

activityId=[52a9af76-e3b5-460b-8136-1c02553767e9]}Access Denied

The reason could be that the user running the cmdlet is not member of the local group "RTC Local User Administrators". Membership of the domain group RTCUniversalUserAdmins will automatically give you membership of the needed local group.

Use whoami /groups in a command window to see your group membership.

(Updated 15 April 2013)

In the Capacity Planning Guidance we describe that the disk requirements for a Lync 2013 front end server, given our usage model, is eight disks configured as two drives.

• One drive will use two disks in RAID 1 to store the Windows operating system and the Lync 2013 and SQL Express binaries
• One drive will use six disks in RAID1+0 to store databases and transaction logs from the two SQL Express instances (RTCLOCAL and LYSS)

If you have front end server with only two disk drives the Install-CsDatabase command run during installation of Lync Server 2013 will automatically place the databases and transaction logs on the non-system disk drive.

However if you have more than two disk drives you can use the following process to specify the disk drive used for database and transaction logs. In the example, the system drive is C:, there is E: drive and F:\CsData should be used for databases and transaction logs.

1. Start the Lync Server 2013 Deployment Wizard and accept the default location on the C: for the binaries
2. Under Deploy perform Step 1 – Install Local Configuration Store
3. When step 1 is done start Lync Server Management Shell and issue the following command:
   1. Install-CsDatabase -DatabasePaths F:\CsData -LocalDatabases
4. Continue with step 2 and the remaining steps in the Lync Server 2013 Deployment Wizard

This approach will give the location of databases and transaction logs as described in the table below.

Please also note that in Lync Server 2013 we create the rtc and rtcdyn databases and corresponding transaction logs with an initial size of 4 Gb. That mean in total 16 Gb. We are doing that to avoid any performance implication by extending the database and transaction log size during normal operations.

On a fresh Lync 2013 front end Step 3 in the above sequence will fail, because the LYNCLOCAL SQL Express instance has not been installed after step 1 in the deployment wizard. To work-around this problem you can do the following:

1. Continue with step 2 in the deployment wizard and let it install the databases on whatever drive it decides
2. After step 2, delete all databases in RTCLOCAL and LYNCLOCAL instances. You can do it via SQL Management Studio or by using the PS script below and replace Lync2013FE with the correct hostname
3. Issue Install-CsDatabase cmd from 3) above
4. Continue with step 3 in the deployment wizard

    $SqlServer = "Lync2013FE"    

    $connstring = "server=" + $SqlServer + "\rtclocal;trusted_connection=true;"

    $connection = new-object system.data.sqlclient.sqlconnection

    $connection.ConnectionString = $connstring

    $connection.Open()

    $command = new-object system.data.sqlclient.sqlcommand

    $command.Connection = $Connection

    $command.commandtext = "drop database rtc"

    $sqladapter = new-object system.data.sqlclient.sqldataadapter

    $sqladapter.selectcommand = $command

    $results = new-object system.data.dataset

    $reccount=$sqladapter.Fill($results) | Out-Null

    $command.commandtext = "drop database rtcdyn"

    $sqladapter.selectcommand = $command

    $results = new-object system.data.dataset

    $reccount=$sqladapter.Fill($results) | Out-Null

    $connection.Close()

    $connstring = "server=" + $SqlServer + "\lynclocal;trusted_connection=true;"

    $connection = new-object system.data.sqlclient.sqlconnection

    $connection.ConnectionString = $connstring

    $connection.Open()

    $command = new-object system.data.sqlclient.sqlcommand

    $command.Connection = $Connection

    $command.commandtext = "drop database lyss"

    $sqladapter = new-object system.data.sqlclient.sqldataadapter

    $sqladapter.selectcommand = $command

    $results = new-object system.data.dataset

    $reccount=$sqladapter.Fill($results) | Out-Null

    $connection.Close()

The Lync Server Backup Service is a new service in Lync 2013 Server used to support disaster recovery (http://technet.microsoft.com/en-us/library/jj205293(v=ocs.15).aspx.

The Lync Server Backup Service supports two categories of data (UserData and CMS), which it will copy between paired pools to keep them synchronized. The implementation use three modules: UserServices.PresenceFocus, ConfServices.DataConf and CentralMgmt.CMSMaster. The modules can operate both in Import or Export mode. The Lync Server Backup Service collects the changes into batches before copying it to the paired pool. The Backup Service is only active on one of the front ends in a pool.

In order to see detailed status from the Lync Server Backup Service use the following cmdlets:

• $BackupStatus = Get-CsBackupServiceStatus –PoolFqdn <pool fqdn>
• $BackupStatus.BackupModules

This will produce output like below:

Identity                    ExportStatus    ImportStatus

--------                    ------------    ------------

UserServices.PresenceFocus  FinalState      NormalState

ConfServices.DataConf       FinalState      NormalState

CentralMgmt.CMSMaster       NotInitialized  NormalState

The table below lists the meaning of Export and Import Status. Please note that the output above is for a pool, which is not the active CMS master. That is why the ExportStatus for CentralMgmt.CMSMaster is NotInitialized.

You use the Configure-EnterprisePartnerApplication.ps1 to create partner application to be used for OAuth with SharePoint 2013 and Lync 2013. The script creates a mail user and assigns management roles to that mail user.

When running the script in an environment with multiple Active Directory domain controllers in the site, you might see the script failing. It happens because it creates the user on one domain controller and then search for it using another domain controller and the search fails.

Creating Partner Application <Lync Enterprise-7da0c6999277459ca10385cb7870b005> using metadata <https://lync.contoso.dk/metadata/json/1>.

Created Partner Application <Lync Enterprise-7da0c6999277459ca10385cb7870b005>.

Creating User <Lync Enterprise-ApplicationAccount> for Partner Application.

Couldn't find object "contoso.dk/Users/Lync Enterprise-ApplicationAccount". Please make sure that it was spelled correctly or specify a different object.

+ CategoryInfo : NotSpecified: (:) [Set-Mailbox], ManagementObjectNotFoundException

+ FullyQualifiedErrorId : A01C78F0,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

+ PSComputerName : e15.contoso.dk

Created User <contoso.dk/Users/Lync Enterprise-ApplicationAccount> for Partner Application.

Assigning role <UserApplication> to Application User <contoso.dk/Users/Lync Enterprise-ApplicationAccount>.

Couldn't find a user with the identity "contoso.dk/Users/Lync Enterprise-ApplicationAccount".

+ CategoryInfo : NotSpecified: (:) [New-ManagementRoleAssignment], ManagementObjectNotFoundException

+ FullyQualifiedErrorId : 55267DAC,Microsoft.Exchange.Management.RbacTasks.NewManagementRoleAssignment

+ PSComputerName : e15.contoso.dk

The solution is to use the –domaincontroller switch to Configure-EnterprisePartnerApplication.ps1 and specify a domain controller. The script will then use that domain controller for all its operations.

This post describes how to configure Exchange 2013 OWA to have IM integration to Lync 2013. Here I would like to give some troubleshooting tips in case you can't get the integration to work.

Web.Config edits

• Make sure you edit the OWA web.config file on the MBX server(s)
• Make sure it has the right format, i.e. no space after the hex characters in the certificate thumbprint and ending /> brackets
  • <add key="IMCertificateThumbprint" value="EA5A332496CC05DA69B75B66111C0F78A110D22" />
  • <add key="IMServerName" value="atl-cs-001.litwareinc.com" />
• Make sure you add the two lines in the right section of the OWA web.config file (<appSettings>)
• Make sure to restart the MSExchangeOWAAppPool after the edit

Certificate

• Make sure that the certificate you use on the MBX server is trusted by the Lync 2013 server and vice versa. Typically this means using certificates from a mutually trusted CA, perhaps the enterprise CA
• Make sure the subject name of the certificate and one of the subject alternative names are the FQDN of the MBX server

OwaVirtualDirectory and OwaMailboxPolicy

• Make sure you have set InstantMessagingEnabled to $true and set InstantMessagingType to Ocs

User

• Make sure the user has a proxy address with SIP type (you can set it in EMS with the cmdlet set-Mailbox <alias> -EmailAddresses @{Add="SIP:<SIP URI, i.e. u@h.com>"})
• Make sure that the CASMailbox representing the user has the appropriate OwaMailboxPolicy

Signing in

• Look for event ID 112 from MSExchange OWA on the MBX server signaling that the Instant Messaging Endpoint Manager was initialized successfully. This happens at first IM sign-in after OWA App Pool restart
• If you get event 112, but the user is still not able to sign in, check certificates and that the user has the SIP proxy address

Lync 2013 Topology

• If the Exchange 2013 MBX server is also hosting a UM dial plan of URITYpe SipName do not add the Exchange 2013 MBX server as a Trusted Application Pool. The Exchange UM integration in Lync 2013 will automatically add the Exchange 2013 MBX server as a trusted server in Lync 2013

Logfile and tracing

• OWA IM Integration writes logfiles to the directory C:\Program Files\Microsoft\Exchange Server\V15\Logging\OWA\InstantMessaging on the MBX server. If there is no logfile in that directory or no InstantMessaging directory, OWA itself has not yet understood that it needs to support IM integration to Lync
• On the Lync 2013 server use SIPStack tracing (All Levels and All Flags) to get an idea of what might be wrong (Use LyncDebugTools.msi http://www.microsoft.com/en-us/download/details.aspx?id=35453)
• On Exchange 2013 MBX you can use OcsTracer.exe in C:\Program Files\Microsoft UCMA 4.0\Runtime\Tracing to see the SIP traffic generated by OWA IM
• To Start: OCSTracer.exe Start /Component:Collaboration,TL_noise,tf_component,tf_diag,tf_protocol,tf_connection /Component:S4,TL_VERBOSE,tf_component,tf_protocol /LogFileMode:NewFile,20
• To Stop and see traces: OCSTracer Stop /Component:Collaboration /component:s4 /OutputFile:traces.txt /View

In this post I described how Lync 2013 Preview can use high-resolution photos available in Exchange 2013 Preview mailboxes. SharePoint Server 2013 is also able to use the same high-resolution photos. The SharePoint-Exchange photo sync feature implements this.

How it works

SharePoint Server 2013 maintains a library of User Photos, just like in SharePoint Server 2010. When SharePoint-Exchange photo sync is enabled, SharePoint's local photo store becomes a cache, and SharePoint Server 2013 treats Exchange 2013 as the master photo store. SharePoint-Exchange photo sync is not a regular sync job that runs on a recurring cycle. Instead, SharePoint Server 2013 requests photos from Exchange 2013 automatically when a user performs an operation that causes a request for their own photo (for example, browsing to their own user profile page). That means that the user needs to have requested his/her own photo, before other users will be able to see it.

When a user with a valid Exchange 2013 mailbox attempts to change their profile photo, SharePoint Server 2013 will launch the Outlook 2013 Web App photo upload dialog.

Two variables (which can be set per web-application) help govern the syncing behavior:

• UserPhotoExpiration (in hours) specifies the minimum time that must elapse before SharePoint Server 2013 will check for a given user's photo again.
• UserPhotoErrorExpiration (in hours) specifies the minimum time that must elapse before SharePoint Server 2013 will check for a given user's photo when it received an error on the previous attempt.

SharePoint Server 2013 is using the Exchange Web Services Managed API V2.0 and Server to Server authentication (S2SOAuth) to be able to read data from Exchange 2013.

Configuration

Let me show how to configure the integration. I will use the following sample environment to illustrate the configuration:

• One Exchange 2013 Client Access server with FQDN e15fe.contoso.com
• One Exchange 2013 Mailbox server with FQDN e15be.contoso.com.
  • The test users have Exchange 2013 mailbox with the primary SMTP address test1@contoso.com and test2@contoso.com
  • High resolution photos have been uploaded to the mailboxes
• One SharePoint Server 2013 server with FQDN sps15.contoso.com
  • A Web Application available at https://sps15 and http://sps15. Alternate access mapping set for https://sps15.contoso.com
  • Appropriate SSL certificate set on the web site in IIS
  • A My Site site collection available at http://sps15/my
  • The test users have My sites available on http://sps15/my
• A DNS record for autodiscover.contoso.com points to e15fe.contoso.com

In the sample environment the programs have been installed on the C: drive.

Step 1: Exchange 2013 Autodiscover Service

Configure the Exchange 2013 Autodiscover service to be available on the FQDN autodiscover.contoso.com. Use the following Exchange Management Shell command on e15fe.contoso.com.

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Step 2: External Url's set

SharePoint Server 2013 use the external Url variants for EWS and ECP when accessing the photos on Exchange 2013. In the sample environment I'll use the internal FQDN's also for external use. Use the following Exchange Management Shell command on e15fe.contoso.com.

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –InternalUrl https://e15fe.contoso.com/ews/exchange.asmx –ExternalUrl https://e15fe.contoso.com/ews/exchange.asmx

Get-EcpVirtualDirectory | Set-EcpVirtualDirectory –InternalUrl https://e15fe.contoso.com/ecp –ExternalUrl https://e15fe.contoso.com/ecp

Step 3: Exchange Web Services Managed API V2.0

Install the EWS Managed API from the link above on sps15.contoso.com. Make sure that the Microsoft.Exchange.WebServices.dll is loaded into the GAC by using GacUtil. Make sure to use the .NET 4 version of GacUtil (C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools after you have installed .NET 4.0 SDK)

GacUtil /i C:\Program Files\Microsoft\Exchange\Web Services\2.0\Microsoft.Exchange.WebServices.dll

Step 4 SharePoint S2SOAuth configuration with Exchange

Now it is time to configure SharePoint to do S2SOAuth with Exchange.  Use the following SharePoint 2013 Management Shell commands:

• New-SPTrustedSecurityTokenIssuer -name "Exchange" -MetadataEndPoint "https://autodiscover.contoso.com/autodiscover/metadata/json/1"
• $sts=Get-SPSecurityTokenServiceConfig
• $sts.HybridStsSelectionEnabled = $true
• $sts.AllowMetadataOverHttp = $false
• $sts.AllowOAuthOverHttp = $false
• $sts.Update()
• $exchange=Get-SPTrustedSecurityTokenIssuer "Exchange"
• $app=Get-SPAppPrincipal -Site http://sps15 -NameIdentifier $exchange.NameId
• $site=Get-SPSite http://sps15
• Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.RootWeb -Scope sitesubscription -Right fullcontrol -EnableAppOnlyPolicy

Step 5 Exchange S2SOAuth configuration with SharePoint

We now need to configure the Exchange 2013 side of things. Use the following Exchange Management Shell commands:

• cd \Program Files\Microsoft\Exchange Server\V15\Scripts>
• .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl https://sps15/_layouts/15/metadata/json/1 -ApplicationType sharepoint

Make sure to restart IIS on both front-end and back-end by issuing the following commands in a command window:

• iisreset e15fe
• iisreset e15be

Step 6 Configure SharePoint 2013 Exchange photo sync

Use the following SharePoint 2013 Management Shell commands:

• $wa = Get-SPWebApplication http://sps15
• $wa.Properties["ExchangeAutodiscoverDomain"] = "autodiscover.contoso.com"
• $wa.UserPhotoImportEnabled = $true
• $wa.UserPhotoErrorExpiration = 1.0
• $wa.UserPhotoExpiration = 6.0
• $wa.Update()

How to try it out?

Sign in to Windows as test1 and use IE to access his My site at http://sps15/my. You should now see the high-resolution photo being shown as the profile photo.

If some reason, the photo is not showing you might be able to diagnose the issue by examining the ULS logs available at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS.

Acknowledgements

Thanks to Ryan, Nathaniel and Sesha for their input to this post.

In this post I described how Lync 2013 Preview could archive content in Exchange 2013 Preview mailboxes. SharePoint Server 2013 is able to search in such archives using the SharePoint Server 2013 eDiscovery site collection.

SharePoint Server 2013 is using the Exchange Web Services Managed API V2.0 and Server to Server authentication (S2SOAuth) to be able to read data from Exchange 2013.

I will now describe how to configure SharePoint Server 2013 to allow a user to discover Lync archived data. The goal of the configuration below is to allow the user test2 to search Lync archived data in Exchange for the user test1.

Configuration

Let me show how to configure the integration. I will use the following sample environment to illustrate the configuration:

• One Lync Server 2013 Enterprise Edition pool with two Lync Server 2013 Front End Servers lyncfe1.contoso.com and lyncfe2.contoso.com.
• Pool FQDN is lync.contoso.com.
• Two test users are enabled with SIP URI test1@contoso.com and test2@contoso.com
• One Exchange 2013 Client Access server with FQDN e15fe.contoso.com
• One Exchange 2013 Prevew Mailbox server with FQDN e15be.contoso.com.
• The test users have Exchange 2013 mailbox with the primary SMTP address test1@contoso.com and test2@contoso.com
• One SharePoint Server 2013 server with FQDN sps15.contoso.com
• A Web Application available at https://sps15 and http://sps15. Alternate access mapping set for https://sps15.contoso.com
• Appropriate SSL certificate set on the web site in IIS 
• A DNS record for autodiscover.contoso.com points to e15fe.contoso.com

In the sample environment, the programs have been installed on the C: drive.

Step 1: Exchange 2013 Autodiscover Service

Configure the Exchange 2013 Autodiscover service to be available on the FQDN autodiscover.contoso.com. Use the following Exchange Management Shell command on e15fe.contoso.com.

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Step 2: Exchange Web Services Managed API V2.0

Install the EWS Managed API from the link above on sps15.contoso.com. Make sure that the Microsoft.Exchange.WebServices.dll is loaded into the GAC by using GacUtil. Make sure to use the .NET 4 version of GacUtil (C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools after you have installed .NET 4.0 SDK)

GacUtil /i C:\Program Files\Microsoft\Exchange\Web Services\2.0\Microsoft.Exchange.WebServices.dll

Step 3 SharePoint S2SOAuth configuration with Exchange

Now it is time to configure SharePoint to do S2SOAuth with Exchange.  Use the following SharePoint 2013 Management Shell commands:

• New-SPTrustedSecurityTokenIssuer -name "Exchange" -MetadataEndPoint "https://autodiscover.contoso.com/autodiscover/metadata/json/1"
• $sts=Get-SPSecurityTokenServiceConfig
• $sts.HybridStsSelectionEnabled = $true
• $sts.AllowMetadataOverHttp = $false
• $sts.AllowOAuthOverHttp = $false
• $sts.Update()
• $exchange=Get-SPTrustedSecurityTokenIssuer "Exchange"
• $app=Get-SPAppPrincipal -Site http://sps15 -NameIdentifier $exchange.NameId
• $site=Get-SPSite http://sps15
• Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.RootWeb -Scope sitesubscription -Right fullcontrol -EnableAppOnlyPolicy

 Step 4 Exchange S2SOAuth configuration with SharePoint

We now need to configure the Exchange 2013 side of things. Use the following Exchange Management Shell commands:

• cd \Program Files\Microsoft\Exchange Server\V15\Scripts>
• .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl https://sps15/_layouts/15/metadata/json/1 -ApplicationType sharepoint

Make sure to restart IIS on both front-end and back-end by issuing the following commands in a command window:

• iisreset e15fe
• iisreset e15be

 Step 5 Give discovery user appropriate permissions

We need to add the user test2 to "Discovery Management" role group to allow test2 to do the discovery. Use the following Exchange Management Shell commands:

• Add-RoleGroupMember "Discovery Management" -member test2

 Step 6 Create a eDiscovery site

Use the following SharePoint 2013 Management Shell commands:

• $template=Get-SPWebTemplate | where-object {$_.title -eq "eDiscovery Center"}
• New-SPSite -Url https://sps15/sites/Discovery -OwnerAlias test2 -Template $template -name "Discovery Center" 

By adding test2 as owner I make sure that the user has the necessary permissions on the site.

Step 7 Set Lync Archiving Policy for test1

Use the following Lync Management Shell commands on lyncfe1.contoso.com to enable archiving to Exchange for test1.

• Set-CsUser test1 –ExchangeArchivingPolicy ArchivingToExchange

Step 8 Generated test data

For both test users sign in to Lync 2013. From test1 send an IM to test2 with the text "eDiscovery Lync Archived test data". Close the conversation windows.

Step 9 Create Exchange content source

We need to add Exchange 2013 as a content source in SharePoint. Use the SharePoint 2013 Central Administration website as follows:

• Central Administration –> Manage Service Applications –> Select the Search Service Application
• Search Administration –> Result Sources –> New Result Source
• Name the Result Source "Exchange"
• Select Protocol to be Exchange
• In the Exchange Source Url enter https://e15fe.contoso.com/ews/exchange.asmx and do not select Use AutoDiscover
• Click OK

 Step 10 Create eDiscovery case

Now we need to create an eDiscovery case using the Discovery web site created in step 6. As test2 sign into Windows and use IE to access the web site https://sps15/sites/discovery.

• Click Create new case
• Give the case the title test1 and add test1 as the end of the URL name
• Click Create

 Step 11 Create eDiscovery set

Now we need to create an eDiscovery set using the eDiscovery case created in step 10.

• Under eDiscovery Sets click new item
• Give the eDiscovery set the name test1
• In the Filter box write "eDiscovery Lync*"
• Click Add & Manage Sources
• Specify test1 in the mailbox field, click the Check Mailbox icon and Click OK

SharePoint will now start a search against the test1 mailbox and should show that it has found 2 Items: 1 item from the Conversation History folder and 1 item from the archived data in the Purges folder.

You can now Save the eDiscovery Set and enable In-Place Hold if needed.

(1 Aug 2012: Updated with information about the AlwaysOn scenario provided by Natasha the PM for CLS)

Centralized Logging Service (CLS) is a new feature in Lync Server 2013 Preview. It provides a mechanism to enable/disable logging across all Lync servers in a deployment  from a single interface and to search the resulting logs from the same interface.

You specify what should be logged based on the scenario you want to investigate. The scenarios supported are AlwaysOn, MediaConnectivity, ApplicationSharing, AudioVideoConferencingIssue, HybridVoice, IncomingAndOutgoingCall, VoiceMail, IMAndPresence, AddressBook, DeviceUpdate, LYSSAndUCS, CLS, SP, WAC, UserReplicator, HostedMigration, MonitoringAndArchiving, LILRLegacy, LILRLYSS, MeetingJoin, RGS, CPS, XMPP and CAA.

The AlwaysOn scenario is special. CLS is designed to have that scenario running by default. This way, when you have an issue you do not have to turn on logging, repro the issues and then get your logs. The hope is that there is enough logging occurring with AlwaysOn that when you have an issue you will already have the logs available. If AlwaysOn does not provide you with enough logs, then you can turn on a particular scenario to get a more verbose set of logs.

CLS is implemented by agents and a controller used by the Lync administrator to interact with CLS.

The Lync Server Centralized Logging Service Agent service (also known as ClsAgent) is running on all Lync 2013 Preview servers in the deployment.  The purpose of the agent is to respond to requests to enable/disable logging and to respond to search requests.

The Lync administrator controls the agents via the ClsController interface. ClsController is a program default installed into C:\Program Files\Common Files\Microsoft Lync Server 2013\ClsAgent. You can specify different parameters to ClsController. You can see detailed usage information about parameters and their values by just running ClsController without parameters.

The typical sequence of commands you want to run are:

• ClsController.exe -start –scenario <scenario> –pools <pool fqdn>
• Repro issue
• ClsController.exe -stop –scenario <scenario> –pools <pool fqdn>
• ClsController.exe  -flush –pools <pool fqdn>
• ClsController.exe  -search –pools <pool fqdn> –components <component> –loglevel <loglevel>

For example to investigate an issue with UCS for a user on the lync.contoso.com pool:

• ClsController.exe -start –scenario lyssanducs –pools lync.contoso.com
• Repro issue
• ClsController.exe -stop –scenario lyssanducs –pools lync.contoso.com
• ClsController.exe -flush –pools lync.contoso.com
• ClsController.exe -search –pools lync.contoso.com –components lyss –loglevel verbose

The last invocation of ClsController will write the resulting log entries to standard output, so you might want to re-direct it to a file by using >.

You can get an understanding of which components are included in which CLS scenarios by the Lync Management Shell command Get-CsClsScenario. Below I’m showing how to find the components or providers in the CPS scenario:

• PS C:\> $scenario=Get-CsClsScenario global/cps
• PS C:\> foreach ($sc in $scenario.provider) { $sc.name }
  CpsDiagnostics
  CpsHostingFramework
  CpsOrbit
  Collaboration
  S4
  Sipstack
  

In Lync Web App 2013 the format used when displaying date and time is taken from the language you have chosen when starting up Lync Web App. It is not using your browser language settings or your desktop date and time format settings.

In the screen shot below English has been chosen. If you click on the language you are able to change to another language to match your date and time format preferences.

If you have configured integration between Lync Server 2013 Archiving and Exchange 2013 (for instructions please see here) you might see error event 56904 and warning event 56902 from LS Data Collection in the Lync Server event log.

These events are reported because the content to be archived is larger than what Exchange 2013 is configured to accept. Lync Server 2013 use Exchange Web Services to writes the content to Exchange.

To configure Exchange 2013 to accept the large content you need to set the MaxSendSize parameter of Set-TransportConfig in Exchange Management Shell to a suitable value. In my lab I use 40 Mb as the limit. The corresponding command is:

Set-TransportConfig -MaxSendSize 40Mb

This blog has been quiet for more than a year, while I’ve been busy working with our new versions of Lync and Exchange,  However now with the public beta I can start blogging again about some of the cool stuff we have included in the new versions. My first post has been posted on NextHop. It’s concerning integration of Exchange 2013 and Lync 2013.

In a previous post I discussed how the policies related to PSTN re-routing and bandwidth policy override worked. In this post I’ll use the same setup and describe how to configure voice routing to support PSTN re-rerouting. I will assume that the calling user is allowed PSTN re-routing by policy and that Alice has been configured with Line URI +4512345678 and Bob with Line URI +4587654321

PSTN re-routing is the ability of the Lync Server to re-route a Lync call via an external network in case bandwidth is restricted. The network is typically the PSTN, but could also be a private PBX infrastructure.

Lync re-routes the call to the Line URI of the called user. It bypass the normal Reverse Number Lookup (RNL), such that the call is not converted back to a Lync call.

The voice policy of the calling user and the normal voice routing configuration are also used for PSTN re-routing. Outbound Routing (OBR) will look to find a matching route (PSTN Usage and number pattern). In order to make sure PSTN re-routing can happen it is therefore necessary to ensure that voice routes are available for the DID range(s) used for Lync users and that PSTN gateways in all sites are listed in those voice routes.

For the setup above the following voice route would enable PSTN re-routing for users with PSTN usage “DK”:

OBR use the following logic when trying to route the call via PSTN re-routing:

• If it can’t find a matching route, i.e. the user is not allowed to call this number or there is no matching pattern, the call is routed to the called users voice mail
• If it finds a matching route it will send the call to one of the returned PSTN gateways
• If multiple PSTN gateways are returned it will try them one by one until the call is successful or there are no more PSTN gateways
• If it happens to try a PSTN gateway located in a remote site the call will fail due to bandwidth restrictions and OBR will try the next returned PSTN gateway.

Let’s try to summarize the different outcomes in the scenario where Alice calls Bob, bandwidth is restricted and Alice has been allowed PSTN re-routing:

Media Bypass is a new feature in Lync 2010 enabling media to flow directly between clients and PSTN gateways. The basic concept is that the client and the Mediation Server exchanges BypassId’s and if the Id’s match each other media bypass is possible, but not guaranteed (as I’ll discuss later). The BypassId’s are assigned either globally, in which case all servers and clients use the same Id, or per network site, in which case the Id is assigned per subnet membership of the servers and clients. You can control if media bypass is used per PSTN Gateway using Set-CsTrunkConfiguration –EnableBypass.

As I wrote above it is the Mediation Server responsible for the PSTN gateway, which will decide if media bypass can be established. It happens during the signaling in the call setup phase. The PSTN gateway is not necessarily involved.

I’ve set it up in my lab and wanted to share some learning's:

• When changing between enabling Media Bypass Globally and enabling it based on sites and regions make sure to sign out and in again on the client after you’ve made the change. The reason is that the client receives its BypassId via in-band provisioning in the mediaConfiguration provisioningGroup

  <provisionGroup name="mediaConfiguration" >
  <propertyEntryList >
  <property name="bypassEnabled" >true</property>
  <property name="internalBypassMode" >Any</property>
  <property name="externalBypassMode" >Off</property>
  <property name="bypassId" >c61755ed-402f-4b3b-86e2-2bd96252a23c</property>
  </propertyEntryList>
  </provisionGroup>
  

• An easy way to determine, if a given call was using media bypass, is to look at the QoE report sent after the call. You can look at it via the Monitoring Server (User Activity Report –> <user you want to look for> –> Details –> Media Quality Report –> Call Information –> Mediation Server bypass call (true/false). You can also look at it in the uccapilog via Snooper. Find the SERVICE message being sent after the call was completed and look in the XML blob for the tag <v2:MediationServerBypassFlag>true</v2:MediationServerBypassFlag>
• As I wrote above the BypassId’s needs to match, but that is not enough to get media bypass. The other requirement is that the two end-points are able to communicate media directly between them. This includes network connectivity, but also that the media encryption level being used by both end-points matches. Out of laziness my PSTN gateway was configured to use TCP and RTP to communicate with the Mediation Server. That worked perfect without media bypass, but it didn’t enable media bypass. The client was configured to RequireEncryption (Set-CsMediaConfiguration –EncryptionLevel) and as such wanted to use SRTP for media. Since the PSTN gateway didn’t accept or offer that media bypass was not working. I had to re-configure my PSTN gateway to use TLS and SRTP to get media bypass working.

I had been doing some re-installation of my lab and was not sure if I had remembered to install the latest CU on all the servers. I created the following script to give me the highest version of any OCS/Lync component installed on my servers. The highest version is an indication of which CU has been installed, but it doesn’t tell you all CU components have been installed on the server.

The script require Windows Remote Management configured on all the servers (winrm quickconfig) and also that the user running it has the necessary permissions. I’ve run it against OCS 2007 R2 and Lync 2010 CU1 servers. No guarantees and your mileage may vary

$computers = "srv1",”srv2”,”srv3”
$sb = {Get-ChildItem 'hklm:\software\microsoft\real-time communications'| foreach-object {Get-ItemProperty $_.pspath}}
foreach ($computer in $computers)
{
    $all = Invoke-Command -ComputerName $computer  -ScriptBlock $sb
   
    # major.minor.build.patch
    $highest = "0.0.0.0"

    foreach ($i in $all)
    {
   
        # get individual components of version
        $a = $i.Version.split(".")
        $b = $highest.Split(".")
        # calculate a total
        $avalue = ([int]$a[0]*1000)+([int]$a[1]*100)+([int]$a[2]*10)+([int]$a[3])
        $bvalue = ([int]$b[0]*1000)+([int]$b[1]*100)+([int]$b[2]*10)+([int]$b[3])
       
        # Compare totals
        if ($avalue -gt $bvalue)
        {
            # we have a new highest version. Save that
            $highest = $i.Version
        }
       
    }
    write-host "Highest version seen on" $computer "is" $highest
}

The official NextHop article is now available here, so I'm removing the text from this post.

In most environments you won’t see this, but depending on your infrastructure you might get a prompt when signing in to Lync similar to the one in the picture below. You might be asking yourself why do I get this prompt?

Background

Microsoft Lync 2010 adds enhanced trust checking when connecting to automatically discovered servers Lync servers or Exchange servers. The additional trust checking has been implemented to enhance the protection against DNS spoofing attacks. Automatically discovered servers are servers found by looking up SRV or A records in DNS based on the SIP URI or primary SMTP address domains as well as DHCP Option 120. Servers specified manually in the Lync client are assumed trusted by the fact that you manually specified them. The same is true for any servers Lync is re-directed to by trusted servers in another domain.

Checking trust

When Lync has discovered a server in DNS it checks it against the list of trusted domains. If the check is successful the server is trusted and the connection is established. If the check is not successful, the above trust prompt is shown, and the user gets the ability to see the certificate being presented by the server and decide if he/she should trust the server. The user can chose to trust the server and connect to it, always trust the server or try to connect to another server. Always trusting a server adds the domain of the server to the list of trusted domains.

The list of trusted domains are compiled using the follow rules:

• Any trusted domains (created by always trusting a server)
• The users SIP URI domain (via AD, the usual sign-in page or manually configured)
• The domain of the Lync server, which  Lync successfully connected to last

When Lync checks a server against the list of trusted domains it loops through the saved domains and test if the server is a member of the domain, either directly or as sub-domains. For example say the list of trusted domains contains d.e and h.i.j. A check for server s1.b.c.d.e will be successful, because b.c.d.e is a sub-domain of d.e. A check for server s2.i.j will not be successful, since i.j is not equal to or a sub-domain of either d.e or h.i.j.

Trust and Certificates

The check of trust is not directly connected to certificates and their subjects or subject alternate name (SAN) entries. It is a pure test against the list of trusted domains. However it is clear that the FQDN of any server Lync connects to needs to be presented in that servers certificate subject and/or SAN. Otherwise the TLS connection can’t be made.

Examples

It might be easier to understand this by way of a couple of examples. Let’s assume the following environment:

• The SIP URI of the user is jeff@fabrikam.com
• server.contoso.com is a Lync SE server in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target server.contoso.com on port 5061
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

In the above environment the list of trusted domains will contain fabrikam.com. When Jeff signs in Lync will find the DNS SRV record _sipinternaltls._tcp.fabrikam.com and it will attempt to connect to server.contoso.com on port 5061. However before it does that it will check if the server is trusted against the list of trusted domains. In this case the check fails and a trust prompt will be shown for server.contoso.com

Let’s now assume that the environment is changed to the following:

• The SIP URI of the user is jeff@fabrikam.com
• server.contoso.com is the Lync director in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
• There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

The list of trusted domains is still fabrikam.com. When Jeff signs in Lync will find the DNS SRV record _sipinternaltls._tcp.fabrikam.com and it will attempt to connect to sip.fabrikam.com on port 5061. First Lync checks it against the list of trusted domains. The test is successful and the trust prompt is NOT shown. The certificate of the Lync director server.contoso.com is checked to verify that it covers sip.fabrikam.com.

Let’s add automatic discovery for Exchange servers to the mix and assume that the environment is changed to the following:

• The SIP URI of the user is jeff@fabrikam.com
• Jeff has an Exchange 2010 mailbox and the primary SMTP address jeff@contoso.com
• There is a DNS A record for autodiscover.contoso.com with IP address 192.168.101.30
• There is a DNS A record for cas.contoso.com with IP address 192.168.101.30
• The Exchange 2010 Client Access Server is running on cas.contoso.com
• server.contoso.com is the Lync director in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
• There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

The list of trusted domains is still fabrikam.com. When Jeff signs in Lync connect as before. However Lync will also try to access Exchange Autodiscover service to get information about how and where it can access Jeff’s mailbox. Lync will use the primary SMTP address domain and try to access the autodiscover service by using the URL’s https://contoso.com/autodiscover/autodiscover.xml and https://autodiscover.contoso.com/autodiscover/autodiscover.xml. In our case it will find the DNS A record for autodiscover.contoso.com and Lync checks it against the list of trusted domains. The check fails and a trust prompt will be shown for autodiscover.contoso.com.

Let’s now assume that the environment is changed to the following:

• The SIP URI of the user is jeff@fabrikam.com
• Jeff has an Exchange 2010 mailbox and the primary SMTP address jeff@contoso.com
• There is a DNS SRV record for _autodiscover._tcp.contoso.com with target autodiscover.fabrikam.com on port 443
• There is a DNS A record for autodiscover.fabrikam.com with IP address 192.168.101.30
• There is a DNS A record for cas.contoso.com with IP address 192.168.101.30
• The Exchange 2010 Client Access Server is running on cas.contoso.com
• server.contoso.com is the Lync director in the environment
• There is a DNS A record for server.contoso.com with the IP address 192.168.101.20
• There is a DNS SRV record _sipinternaltls._tcp.fabrikam.com with target sip.fabrikam.com on port 5061
• There is a DNS A record for sip.fabrikam.com with the IP address 192.168.101.20
• The user has never before connect to Lync server on this PC
• Automatic configuration is selected in Lync

The list of trusted domains is still fabrikam.com. When Jeff signs in Lync connect as before. Lync will try to access Exchange Autodiscover service as above, but will fail since there is no A record for autodiscover.contoso.com. Lync will then try to find a SRV record for _autodiscover._tcp.contoso.com and it will get the target autodiscover.fabrikam.com returned. Lync will check autodiscover.fabrikam.com against the list of trusted domains and it will find a match. This means the server is trusted and the prompt above is NOT shown.

Best practices

When configuring DNS to support automatic discovery of Lync and Exchange servers for Lync please follow these best practices:

• Make sure that the target of any SRV record is in a domain, which will be automatically trusted by Lync per the rules above
• Make sure that the target of any SRV record is an A record. Using CNAME records as targets is not supported by Lync and is not allowed per RFC2782 – A DNS RR for specifying the location of services (DNS SRV)
• Make sure certificates used on Lync and Exchange servers includes all the FQDN’s used as targets for the SRV records. Otherwise Lync won’t be able to setup a TLS connection to the server

Thanks to Brian for background information and review.

You might have wondered exactly which Active Directory permissions the Microsoft Lync Server 2010 PowerShell cmdlets Grant-CsSetupPermission and Grant-CsOuPermission grants which Active Directory group? If so, I hope the following post will stop your wondering.

At the end of this post is a table showing the content of each Active Directory property set referenced in the tables below.

Grant-CsSetupPermission will give the RTCUniversalServerAdmins group the following permission on an OU after having run Grant-CsSetupPermission on the OU.

Running Grant-CsOuPermission -ObjectType User on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission -ObjectType Contact or AppContact on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission -ObjectType Computer on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission –ObjectType Device on an OU will grant the following groups the permissions shown in the table below.

Running Grant-CsOuPermission –ObjectType InetOrgPerson on an OU will grant the following groups the permissions shown in the table below.

Relevant PropertySets and their content are shown below.

This post is written by my colleague Thomas Binder.

With the recent release of the first updates for Lync Server 2010 and all clients for Lync, it is probably the first time you update your new Lync devices (for details on the update process please refer to http://technet.microsoft.com/en-us/library/gg182592.aspx ).

While for the Polycom CX700 and LG-Nortel IP8540 (aka “Tanjay”) – as in OCS 2007 and in OCS 2007 R2 – dedicated update files per language are provided, for all other phones (codename “Aries”: Polycom CX500, Polycom CX600, Aastra 6725ip, Aastra 6721ip) you will find only a single file.

After importing the German and the English update files to my server for the “Tanjay” and the update for Aries, I can see the following pending firmware versions in my Lync Server Control Panel:

As you can see, for the CX700 the English image (ENU) and the German image (DEU) are now on the server, as indicated by the column “Locale”. However, for the other devices you will find only the Locale “ENU”, no matter which language you chose during the installation.

If you are wondering now where the other languages went: all of them are included in a single file. It is listed with the locale “ENU” but in fact it is a MUI (Multi-lingual User Interface). Just approve the update and users will be able to choose their preferred language on the phone. After upgrading from RTM, the language on the device will be English. To change the language, users can do so on the phone (Settings > Language screen), or they can hard-reset the phone and start from scratch.

An overview of all optimized IP phones for Lync can be found here: http://technet.microsoft.com/en-us/lync/gg278172

Lync 2010 Phone Edition for Polycom CX700 and LG-Nortel IP Phone 8540: http://support.microsoft.com/?kbid=2493722

Lync 2010 Phone Edition for Aastra 6721ip and Aastra 6725ip: http://support.microsoft.com/?kbid=2493724

Lync 2010 Phone Edition for Polycom CX500, Polycom CX600, and Polycom CX3000: http://support.microsoft.com/?kbid=2493723

Tom's post on Localized Languages for Lync Server and Clients http://blogs.technet.com/b/toml/archive/2011/01/26/localized-languages-for-lync-server-and-clients.aspx

Microsoft Lync 2010 is able to use the Wireless Access Point, a laptop is connected to, as the key to show your location. The client sends the so called Basic Service Set Identifier (BSSID), which can be seen as an identifier for the wireless access point, to the Location Information Service (LIS) and it will return the location information for that wireless access point as it is defined in LIS.

However today I ran into the following situation. I used my Windows 7 laptop and was connected to wireless access point A. Lync was showing the correct location LocationA. I then put the laptop to sleep and went to another building far away from wireless access point A. I resumed the laptop and Lync was still showing my location as LocationA. This puzzled me, since there was no way that my laptop could still be connected to wireless access point A. Something was wrong.

I looked at the wireless configuration on the laptop using netsh wlan show interface and netsh wlan show networks mode=bssid. The interface command showed my laptop being connected to a BSSID, which didn’t appear in the list of BSSID’s my laptop could see (as listed by netsh wlan show networks mode=bssid). Strange.

Turns out there is an issue in Windows 7 where it will report the wrong BSSID to applications after the laptop has been resumed. The issue is described in http://support.microsoft.com/kb/2385405 and there is a hotfix available. So Lync was being given the old BSSID and used that to get my location from LIS. It was doing the right thing, but it was based on stale information. I installed the hotfix and couldn’t repro the issue afterwards.

Yesterday we released Cumulative Update 1 (CU1)  for Lync 2010 and it includes very good news for users of location information in Lync 2010, especially for deployments outside of the United States.

Prior to CU1 location information loaded into the Location Information Service (LIS) in Lync Server 2010 had to be validated against the Master Street Address Guide (MSAG) in the US before the location information was automatically shown in Lync. The reason for this requirement is the relationship with the support for E-9-1-1 in the US, where the address information needs to very specific and validated before it can be used. The MSAG only contains addresses in the US and as such it was not possible to validate addresses outside of the US.

With CU1 Lync will automatically show non validated location information, if there is only one location returned from LIS based on the request the Lync client sent to LIS. This means that it now makes sense to load information for locations outside of the United States into LIS for automatic display in Lync 2010.

Microsoft Lync Server 2010 includes a range of performance monitor counters showing the health and performance of the system. One of the counters is MEDIA – 000 – Global health counter in the group LS:MEDIA – 00 – Operations. The counter indicates the Global health of the media stack and it can take 5 values:  0 means DISABLED, 1 is NORMAL, 2 is LIGHTLOAD, 3 is HEAVYLOAD and 4 is OVERLOADED. However recently someone reported that they were seeing a value of 6 for this counter. I checked on my system and I saw the value 7. What was going on?

It turns out that counter I saw as 7 was the _Total counter. This counter shows the number of media stack instances on the server. On my server I had 7 instances running as you can see on the screenshot below. Each one of those counters were 1, which means the load was normal.

Many of the Synthetic Transactions (ST) in Lync Server 2010 allow you to specify a user and the corresponding user credentials, but do you always have to specify the user credentials? The answer depends on from where you run the ST.

If you run the ST from a server, which is trusted by the Lync server you run the ST against, you don’t have to specify user credentials. The trust is established by defining the server in the Lync topology, install Lync on the server and assign a certificate to it. The server running the ST will then use MTLS when communicating with the target Lync server.

If you run the ST from a server with only the Lync Admin tools installed on it you need to specify user credentials. It is necessary because otherwise it is not possible for the ST to authenticate against the Lync server it is targeting, since the server running the ST is not trusted. If you forget to specify user credentials you might see an error message like A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider:SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified).

Thanks to Antenehe and Fatih for background information.