Update 11/26/13 - I have release an updated version of the reports. This version of the reports includes a Dashboard. See the changelog below for more details on what's new.
The Sample Lync Server Archiving Report is an update to the popular Sample OCS Archiving Report, however this report has been completely redesigned based on feedback from the community. We've expanded the report to include more information from the archiving database and we've changed the layout of the report to make the information easy to consume.
Features
The reports have been tested against Lync Server 2010 and Lync Server 2013 using SQL Reporting Services 2012. You will need to have a functioning SQL Reporting Services server before trying to deploy this report.
Installing the Reports
If there are users that will be running the Dashboard report that don't have dbo rights to the LcsLog database, they may get the following error:
An error has occurred during report processing. (rsProcessingAborted) Query execution failed for dataset 'DatabaseVersion'. (rsErrorExecutingCommand) The EXECUTE permission was denied on the object 'DbGetVersion2', database 'LcsLog', schema 'dbo'.
This is because they don't have access to run the DbGetVersion2 stored procedure. You will need to perform the following additional steps to grant access:
In SQL Server Management Studio, add the user or group that contains the users you want to be able to run the Dashboard report in the Security > Users folder under the LcsLog database. Right-click on the user and select Properties. Make sure that the Securables page is displayed:
Click on the Search button:
Make sure that Specific objects is selected and click OK. Click on the Object Types button:
Select Stored procedures and click OK. Click on the Browse button:
Select [dbo].DbGetVersion2] and click OK:
Click OK:
Select the Grant check box for the Execute permission. Click OK.
The reports are now ready to be used.
Using the Reports
Dashboard
Note: You may need to click on the image above in order to read the text.
The Dashboard report shows you an overview about information contained in the archiving database. You can see information about the SQL Server that hosts the archiving database, as well as, information about the archiving database itself. The number of instant messages and conferences are shown for the time period selected as well as top users for instant messages and conferences.
Search
The Search report is the main report that you will use. As it's name implies, this is the report that you will use to generate your queries against the archiving database. The report requires a couple pieces of data, namely the SIP addresses of the user's that you want to search against and the date range of the search. If you want to search every user or if you only want to search for any communications to/from a single user, use the NULL option. This essentially means any user. You can also pick the SQL Server you want to run the query against.
The results are broken up into two sections, Instant Messages and Conferences. Clicking on the link will drill down into more information for that conversation.
Conversation Details Report
Drilling down into an instant message conversation will display something similar to above. You can see when and who sent the initial message, as well as the client versions of the users, and a transcript of the conversation.
Conference Details Report
Drilling down into a conference shows you a lot of information gathered by the Archiving Server role. You can expand each section to take a look at the data that was captured.
Please leave any questions/comments/feedback in the comments section below.
Click here to download the latest version of the report.
Changelog
November 2013 Release
Search - 1.2
Conversation Details Report.rdl - 1.1
Conference Details Report - 1.1
Dashboard - 1.0
Known Issues
Update 5/31/13 - Added information about using "Prepare first Standard Edition server" to add firewall rules.
I came across this issue while testing paired pool fail-over. The issue is dependent on a couple of things, namely how you configure your base OS server build and when you paired the Standard Edition Servers. For me this became an issue when I performed the following steps in this order:
With the CMS failed over to the second Standard Edition Server, I was unable to access the CMS from any server except the second Standard Edition Server. Trying to download the topology in Topology Builder on the first Standard Edition Server returned the following:
Running Get-CsBackupServiceStatus on the first Standard Edition Server to check the state of the Lync Server Backup Service returned the following:
However, running the same cmdlets on the second Standard Edition Server returned different results:
Also, the second Standard Edition Server was logging the following in the Lync Server Event Log every 2 minutes:
Log Name: Lync ServerSource: LS Backup ServiceDate: 4/28/2013 11:21:01 AMEvent ID: 4090Task Category: (4000)Level: InformationKeywords: ClassicUser: N/AComputer: TEST-LS15-SE2.test.deitterick.comDescription:Microsoft Lync Server 2013, Backup Service central management backup module performs a full sync export.
At the same time the first Standard Edition Server was logging the following errors in the Lync Server Eventlog:
Log Name: Lync ServerSource: LS Backup ServiceDate: 4/28/2013 11:27:15 AMEvent ID: 4095Task Category: (4000)Level: ErrorKeywords: ClassicUser: N/AComputer: TEST-LS15-SE1.test.deitterick.comDescription:Failed to read topology from Master Central Management database Microsoft Lync Server 2013, Backup Service will continuously attempt to retrieve the topology.
While this condition persists, the module will not be able to perform backup.Exception: Could not connect to SQL server : [Exception=System.Data.SqlClient.SqlException (0x80131904): 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) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, Boolean withFailover) at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, Boolean withFailover) at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout) at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance) at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions) at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) at System.Data.SqlClient.SqlConnection.Open() at Microsoft.Rtc.Common.Data.DBCore.PerformSprocContextExecution(SprocContext sprocContext)ClientConnectionId:00000000-0000-0000-0000-000000000000]Cause: Possible issues with Master Backend databaseResolution:Ensure that the SQL Server hosting the Master Central Management is running.
Log Name: Lync ServerSource: LS Backup ServiceDate: 4/28/2013 11:27:15 AMEvent ID: 4082Task Category: (4000)Level: ErrorKeywords: ClassicUser: N/AComputer: TEST-LS15-SE1.test.deitterick.comDescription:Microsoft Lync Server 2013, Backup Service central management backup module failed to complete import operation.
Configurations: Backup Module Identity:CentralMgmt.CMSMasterWorking Directory path:\\TEST-LS15-SE1.test.deitterick.com\share\1-BackupService-4\BackupStore\TempLocal File Store Unc path:\\TEST-LS15-SE1.test.deitterick.com\share\1-BackupService-4\BackupStoreRemote File Store Unc path:\\TEST-LS15-SE2.test.deitterick.com\share\1-BackupService-3\BackupStore
Additional Message: Exception: Microsoft.Rtc.BackupService.ModuleUnavailableException: Backup module is temporarily unavailable at this point. Reason: CMS backup module is not initialized yet. at Microsoft.Rtc.BackupService.BackupModules.CentralMgmtBackupModule.CheckModuleAvailability(Nullable`1 primaryPool) at Microsoft.Rtc.BackupService.BackupModules.CentralMgmtBackupModule.ApplyChanges(Unzipper unzipper, String& newCookie, Boolean& forceSetErrorState) at Microsoft.Rtc.BackupService.BackupModuleHandler.ReceiveBackupDataTask.ApplyChanges(Boolean& forceSetErrorState) at Microsoft.Rtc.BackupService.BackupModuleHandler.ReceiveBackupDataTask.InternalExecute() at Microsoft.Rtc.Common.TaskManager`1.ExecuteTask(Object state)
Cause: Either network or permission issues. Please look through the exception details for more information.Resolution:Resolution
Log Name: Lync ServerSource: LS Backup ServiceDate: 4/28/2013 11:30:45 AMEvent ID: 4080Task Category: (4000)Level: ErrorKeywords: ClassicUser: N/AComputer: TEST-LS15-SE1.test.deitterick.comDescription:Microsoft Lync Server 2013, Backup Service central management backup module failed to complete export operation.
Additional Message: Exception: Microsoft.Rtc.BackupService.ModuleUnavailableException: Backup module is temporarily unavailable at this point. Reason: CMS backup module is not initialized yet. at Microsoft.Rtc.BackupService.BackupModules.CentralMgmtBackupModule.CheckModuleAvailability(Nullable`1 primaryPool) at Microsoft.Rtc.BackupService.BackupModules.CentralMgmtBackupModule.ConfirmChanges(String cookie) at Microsoft.Rtc.BackupService.BackupModuleHandler.SendBackupDataTask.ConfirmChanges(String cookie) at Microsoft.Rtc.BackupService.BackupModuleHandler.SendBackupDataTask.ConfirmChangesAndPrepareCookieToSync(Boolean primaryDataExists, Boolean secondDataExists, CookieContainer& oldCookie, Boolean& forPrimaryBatch) at Microsoft.Rtc.BackupService.BackupModuleHandler.SendBackupDataTask.InternalExecute() at Microsoft.Rtc.Common.TaskManager`1.ExecuteTask(Object state)
The issue is that the Windows Firewall is blocking access to SQL. If you compare the Windows Firewall rules on the first Standard Edition Server to the rules on the second Standard Edition Server, you'll notice that 2 rules are missing on the second Standard Edition Server:
This is why access to the CMS on the second Standard Edition Server is failing except from the second Standard Edition Server. These two rules were added to the first Standard Edition Server when I ran the "Prepare first Standard Edition server" step in the Deployment Wizard. This is why they're on the first Standard Edition Server, but not the second. The fix is just to manually add these rules to the second Standard Edition Server. Once the rules are added, you'll be able to access the CMS from other Lync Servers. This will also resolve the ErrorState that Get-CsBackupServiceStatus is displaying for the first Standard Edition Server.
If you had decided to pair the Standard Edition Servers when you first authored the topology, you could have just ran the "Prepare first Standard Edition server" step in the Deployment Wizard on both Standard Edition Servers:
This would have created the required SQL instance and placed the correct rules in the Windows Firewall:
> Creating firewall exception for SQL instance
netsh advfirewall firewall add rule name="SQL RTC Access" dir=in action=allow program="c:\Program Files\Microsoft SQL Server\MSSQL11.RTC\MSSQL\Binn\sqlservr.exe" enable=yes profile=anyOk.
> Creating firewall exception for SQL Browser
netsh advfirewall firewall add rule name="SQL Browser" dir=in action=allow protocol=UDP localport=1434Ok.
Of course, if you have the Windows Firewall disabled, you wouldn't run into this issue, but it's not recommended to disable the Windows Firewall! The important thing to remember is to make sure that the Windows Firewall rules on your paired Standard Edition Server are setup correctly. Otherwise you might be in for a surprise when practicing your disaster recovery plan!
Update 7/11/13 - Added "How Do I View Archived Content?" section
Lync Server 2013 has made a couple of changes to what can be archived and where that archived data can be stored.
What's New?
With the collocation of the Archiving Server role onto the Front End Servers, we've eliminated the need for a separate Archiving Server in Lync Server 2013. This will help to reduce the server footprint required. The Archiving service uses Unified Data Collection Agents that are responsible for capturing data and are located on all Front End Servers and Standard Edition Servers. This also means that MSMQ is no longer needed! It has been replaces by LySS (Lync Storage Service). Also, you now have the choice to use Lync for the archiving store or Exchange Server 2013. However, you can't archive to both locations at the same time. Archiving to Lync is similar to previous versions. The archived information is stored in the LcsLog database in SQL. If you decide to use Exchange Server 2013 are the archiving store, you will be using OAuth and EWS to deliver the archived data to Exchange Server 2013. Archiving also supports SQL mirroring for high availability and the database can be collocated in the same instance as the Front End Server databases, or it can be in a separate instance.
What Information Can Be Archived?
The following types of content can be archived:
The following types of content are not archived:
The Lync Server 2013 Archiving service does not archive Persistent Chat conversations. To archive Persistent Chat conversations, you must enable and configure the compliance service, which is a component that can be deployed with the Lync Server 2013 Persistent Chat Server.
How Archiving to Lync Works
The first thing is to enable archiving. You can do that in the Lync Server 2013 Control Panel or via the Lync Server Management Console:
EnableArchivingIndicates which items (if any) are saved to the archiving database. Valid values are:
Once archiving is enabled and an Archiving Policy is applied to your users, the Archiving Data Collection Agent on each of the Front End Servers in the pool will monitor for IMs and/or Web Conferences that need to be archived. It will send those to be archived communications to the LySS. The LySS will then write it to the appropriate repository, either SQL or Exchange Server 2013.
How Archiving to Exchange Server 2013 Works
The process for archiving to Exchange Server 2013 works similarly to archiving to SQL. When configuring the archiving settings for Exchange Server 2013, remember to check the box for Exchange Server integration.
EnableExchangeArchivingWhen set to True, Lync Server 2013 instant message and conferencing transcripts are stored in Microsoft Exchange Server 2013 rather than a separate SQL Server database. Note that if you enable Exchange archiving then users will be managed by the Exchange archiving policies instead of Lync Server 2013 archiving policies. The default value is False.
Lync Server 2013 will use OAuth to connect to the user's mailbox in Exchange Server 2013. You will need to configure both Lync Server 2013 and Exchange Server 2013 for Oauth. You can refer to the Configure OAuth Authentication TechNet article for Exchange Server 2013 and the Managing Server-to-Server Authentication (Oauth) and Partner Applications TechNet article for Lync Server 2013. For users with a mailbox on Exchange Server 2013 and on In-Place hold the Exchange Archiving Policies override Lync Server archiving policies. You can also set the archiving policy manually for individual users using the Set-CsUser to select the archiving policy:
ExchangeArchivingPolicyIndicates where the user's instant messaging sessions are archived. Allowed values are:
Where in Exchange Server 2013 are Archived Lync Messages Stored?
When the user is set to archive into Exchange Server 2013, the messages are stored in a hidden folder (Recoverable Items > Purges) in their mailbox. One way to verify this is to use EWSEditor:
Opening up the Purges folder will show you all the conversations that have been archived for that user.
Best Practices
One thing to check when setting up archiving to either SQL or Exchange Server 2013 is to run the Get-CsArchivingConfiguration cmdlet make sure that ArchiveDuplicateMessages is set to True:
From the Set-CsArchivingConfiguration TechNet article:
The ArchiveDuplicateMessages parameter specifies how "cross-pool" instant messages should be archived. Consider a simple example: Ken Myer (with an account in Pool 1) sends an instant message to Pilar Ackerman, who has an account in Pool 2. Pilar, in turn, sends a reply to Ken’s instant message. If ArchiveDuplicateMessages is set to False, then (based on a built-in algorithm) the session transcript will be logged in either Pool 1 or Pool 2, but not both. If ArchiveDuplicateMessages is set to True (the default value), the transcript will be logged in both pools.
Another parameter to look at and possibly adjust depending on your company policies is CachePurgingInterval. From the Set-CsArchivingConfiguration TechNet article:
This parameter indicates how often (in hours) the system is purged of transcripts where none of the participants have been enabled for archiving. By design, all group IM sessions and conferencing sessions are recorded when they take place. At the specified interval, the system determines whether any of the participants in these sessions have been enabled for archiving. If the system finds a session where none of the participants have been enabled for archiving, then that transcript will be deleted from the database. The CachePurgingInterval property can be set to any integer value between 4 and 168, inclusive. The default value is 24.
How Do I View Archived Content?
One way to view archived data in SQL you can use the Export-CsArchivingData cmdlet. This will export P2P and conference data to .eml messages.
This will export the conversations to the output folder and create folders for each date that a matching conversation was found:
If you open one of the folders you will see all of the conversations listed. The file names have conf or p2p at the end so that you can quickly tell conferences apart from 1:1 conversations. The conversations are stored as .eml files. This means that you can open them using Outlook.
Opening one of the messages using Outlook will show you the transcript of that conversation:
Another way is to use a third party tool or report to pull information out of the archiving database. I have created a Sample Lync Server Archiving Report that you can use:
You can find more information on the report, including the download link, here.
I came across this issue while troubleshooting dialing issues at a customer. When a Lync 2013 user placed an outbound call to the PSTN, the call failed. On the gateway we could see that the calling party's number wasn't being translated properly. The interesting thing was that we already had a trunk configuration setup with a calling number translation rule configured:
The above rule should be translating the calling party's number to:
However, looking at the gateway, we can see that this isn't happening:
INVITE sip:94255550105@mp114-red.lab.deitterick.com;user=phone SIP/2.0FROM: "William Cooper"<sip:+14255550101;ext=0101@lab.deitterick.com;user=phone>;epid=3316DAF438;tag=861f7b5aTO: <sip:94255550105@mp114-red.lab.deitterick.com;user=phone>
For some reason the full E.164 phone number is being sent to the gateway. The reason this was happening was because when the user's line URI was configured, it was configured with an E.164 extension (;ext=0101). The calling number translation rule we configured is explicitly looking for 12 digits. If you enter the full E.164 phone number including the extension, which is what Outbound Routing is sending, no match is found:
The solution is really simple, you just need to account for the E.164 extension in the calling number translation rule:
The pattern to match is:
^\+1(42555501\d{2})(;ext=\d{4})?$
As you can see I've added the E.164 extension to the pattern to match string. I've also added the ? after it. This means that this rule will also apply if the calling party's number doesn't have an E.164 extension assigned. Now when testing the rule, you can see that it succeeds using both formats:
Now when the gateway receives the call, the calling party's number is properly formatted properly:
INVITE sip:94255550105@mp114-red.lab.deitterick.com;user=phone SIP/2.0FROM: "William Cooper"<sip:4255550101@lab.deitterick.com;user=phone>;epid=3316DAF438;tag=f9a5772c0TO: <sip:94255550105@mp114-red.lab.deitterick.com;user=phone>
If you are including the E.164 extension on your Lync 2013 users and you need to apply calling number translation rules, remember that you'll need to account for the extensions when building your rules.
Update 4/8/13 - Added information about change to KB2760445 automatically updating.
I came across this issue in my lab the other day. I noticed that in Hyper-V Manager both of my Office Web Apps Servers had really high CPU utilization:
It's pretty rare that one of my VMs would be doing that much to consume that much of the CPU, so I looked at Task Manager on both of the VMs and saw that they were both pegging the processor:
Neither server should be this busy, so I checked out the Application Event Log to find out what was going on and found the following errors:
Log Name: ApplicationSource: .NET RuntimeDate: 3/29/2013 6:11:08 PMEvent ID: 1026Task Category: NoneLevel: ErrorKeywords: ClassicUser: N/AComputer: LAB-OWA1.lab.deitterick.comDescription:Application: WordViewerWfeWatchdog.exeFramework Version: v4.0.30319Description: The process was terminated due to an unhandled exception.Exception Info: System.TypeInitializationExceptionStack: at Microsoft.Office.Web.Common.ServiceInstanceFinder.GetLocalAgentInstance(Microsoft.Office.Web.Common.OfficeServiceType) at Microsoft.Office.Web.Common.WatchdogHelper.PrepareRegistrations(Microsoft.Office.Web.Common.OfficeServiceType) at Microsoft.Office.Web.Common.WatchdogHelper.WatchMachines(Microsoft.Office.Web.Common.OfficeServiceType, CheckServiceInstance, Microsoft.Office.Web.Common.OfficeServiceType, System.String) at Microsoft.Office.Web.WordViewerWatchdog.Wfe.Program.Main()
Log Name: ApplicationSource: Application ErrorDate: 3/29/2013 6:11:08 PMEvent ID: 1000Task Category: (100)Level: ErrorKeywords: ClassicUser: N/AComputer: LAB-OWA1.lab.deitterick.comDescription:Faulting application name: WordViewerWfeWatchdog.exe, version: 15.0.4481.1000, time stamp: 0x50ee5a74Faulting module name: KERNELBASE.dll, version: 6.2.9200.16451, time stamp: 0x50988aa6Exception code: 0xe0434352Fault offset: 0x000000000003811cFaulting process id: 0x17e8Faulting application start time: 0x01ce2cca4f9a878fFaulting application path: C:\Program Files\Microsoft Office Web Apps\WordViewerWfeWatchdog\WordViewerWfeWatchdog.exeFaulting module path: C:\Windows\system32\KERNELBASE.dllReport Id: 8e4fbe96-98bd-11e2-93f0-00155d010f10Faulting package full name: Faulting package-relative application ID:
There were tons of these errors in the Application Event Log. Recently an update for Office Web Apps Server 2013 was installed:
Since I had Microsoft Update enabled on the servers, the update was installed automatically:
Unfortunately Office Web Apps Server 2013 has specific steps that need to be followed in order to correctly apply updates. Those steps are detailed in the Apply software updates to Office Web Apps Server TechNet article. Since I let Microsoft Update automatically install the updates, the machines weren't removed from the Office Web Apps Server farm before the update was applied, which is what caused the errors listed above. Also unfortunate is that KB2760445 doesn't have an uninstall option. This means that to fix this issue you will need to uninstall Office Web Apps Server 2013, reinstall, and setup the Office Web Apps Server farm again:
Once Office Web Apps Server 2013 is installed again, and before you recreate the Office Web Apps Server farm, download and install KB2760445.
Note: You may need to restart the server in order for the Office Web Apps Server 2013 PowerShell cmdlets to be loaded back into PowerShell by default.
After installing KB2760445 and recreating the Office Web Apps Server farm, CPU utilization on the servers is back to normal:
In the future, to correctly install updates for Office Web Apps Server 2013, follow the steps listed in the Apply software updates to Office Web Apps Server TechNet article.
Note: A change was made to the way Microsoft Update handles KB2760445. The update is no longer installed automatically during the Windows Update maintenance window. An administrator will now need to manually installed the update:
Before applying the update, you will still need to follow the steps listed in the Apply software updates to Office Web Apps Server TechNet article!
Update 6/23/13 - Added information about modifying the Monitoring Reports Data Sources connection string.
I was playing around with the Lync Server 2013 Monitoring Reports and decided to deploy it to both of my SQL Servers in my lab. I have a SQL mirror setup and I installed Reporting Services on both servers. My initial thought was to use a hardware load balancer to distribute the traffic to both Reporting Services Servers. This would also give me high availability within the site for the Monitoring Reports. However, when I went to deploy the Monitoring Reports to the server acting as the SQL mirror, I received the following error:
Cannot grant ReportsReadOnlyRole to user "LAB\srvLyncReports". For details, see the following error message:Exception calling "Create" with "0" argument(s): "Create failed for User 'LAB\srvLyncReports'."
From the error message it looks like the Deploy Monitoring Reports wizard can't assign rights to the service account in SQL. Opening up the SQL instance in SQL Server Management Studio on the SQL mirror you can see that all of the databases are listed and mirroring is working correctly:
However when I go into the properties for the service account and click on the User Mapping page, I received the following message:
One or more databases are inaccessible and will not be displayed in list.
When I tried the same thing on the primary SQL Server, all of the databases are listed correctly and you can see that the service account is assigned ReportsReadOnlyRole:
It appears that you can only assign permissions to databases on the primary SQL Server in the mirror and the Deploy Monitoring Reports wizard won't continue unless it can access the databases, even though the permissions are already set on the primary. At this point the Monitoring Reports are only deployed to the primary SQL Server. They don't get replicated to the mirror, since Reporting Services doesn't participate in the SQL mirroring that is configured. Looking at the SQL Server Reporting Services (SSRS) website on the SQL mirror, you can see that this is the case:
So in order to publish the Monitoring Reports to the SQL mirror you will need to fail the databases (LcsCDR and QoEMetrics) over to the SQL mirror. You can accomplish this by running the Invoke-CsDatabaseFailover cmdlet:
This will make just the Monitoring Server databases active on the SQL mirror. You can confirm this in SQL Server Management Studio:
With the Monitoring Server databases active on the SQL mirror, you can now run the Deploy Monitoring Reports wizard and deploy the reports:
You can confirm the reports were published by going to the SSRS website on the SQL mirror:
Once you have successfully deployed the Monitoring Reports to the SQL mirror you can fail the Monitoring Server databases back to the primary SQL Server. Now that both SQL Servers have the Monitoring Reports deployed, the Lync Server 2013 Control Panel will display both servers under the View Monitoring reports section:
However, if you try to view the Monitoring Reports from the SQL Server that isn't currently the primary for the Monitoring databases, you will receive the following error message:
This is because connection string data sources is pointing to the local SQL Server:
Connection string: data source=(local);initial catalog=LcsCDR
In order to make the reports more resilient, you need to edit the connection string and add the SQL mirror. The connection string should look like:
data source=(local);Failover Partner=LAB-SQL2;initial catalog=LcsCDR
You will need to do this for both Data Sources (CDRDB and QMSDB) on both the primary SQL Server and on the SQL mirror. This way, no matter which server hosts the Monitoring databases and which SSRS website you view the reports from, it will just work! Now I could load balance the SSRS website to both SQL Servers if I wanted.
In the example above, I chose to install SSRS on both the primary SQL Server and on the SQL mirror. If you were just using a single SSRS website, then you would just need to do the last steps to modify the connection string on the Data Sources. That process is documented in the Associating Monitoring Reports with a Mirror Database TechNet article.
I ran into an interesting issue while trying to setup SQL mirroring with a witness in my lab. When installing the databases and setting up mirroring in Topology Builder:
The wizard kept failing when trying to setup the mirror:
Looking at the log file I saw the following errors listed:
Error: DsRoleGetPrimaryDomainInformation failed with error "6BA".
Error: An error occurred: "Microsoft.Rtc.Management.ADConnect.CannotGetDomainInfoException" "DsRoleGetPrimaryDomainInformation failed with error "6BA"."
Unfortunately neither of the error messages provided much useful information on why the error was occurring. I made sure that connectivity to Active Directory was OK and that my Domain Controllers were working properly since the error message made reference to AD. With everything checking out OK and the Install Database wizard still failing in Topology Builder, I decided to run the command manually from the Lync Server Management Shell. Since I was setting up mirroring, Topology Builder was running the Install-CsMirrorDatabase cmdlet. So, I ran that cmdlet from the Lync Server Management Shell using the appropriate parameters as well as including the Verbose parameter. You can find all of the parameters documented in the Install-CsMirrorDatabase TechNet article. Even though the cmdlet failed, this time the error message provided in PowerShell gave me enough information to help me solve the issue:
Install-CsMirrorDatabase : Command execution failed: Cannot setup mirroring because there is an error validating the version of the SQL Server instances. Verify that the SQL Server instances are available. Exception: Microsoft.SqlServer.Management.Common.ConnectionFailureException: Failed to connect to server LAB-SQL-WIT.lab.deitterick.com\SQLEXPRESS. --->System.Data.SqlClient.SqlException: 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)
From the error message above, you can see that the error was actually happening while trying to connect to the SQL witness. In this case I had installed SQL Express in my lab to act as the SQL witness. Once I saw the error message I remembered that SQL Express doesn't allow remote connections by default. In order to allow remote connections I needed to open SQL Server Configuration Manager, expand SQL Server Network Configurations, click on Protocols for SQLEXPRESS, and set TCP/IP to Enabled:
With TCP/IP enabled, this time when running the Install Database wizard from Topology Builder, I was able to successfully complete setting up SQL mirroring with a witness:
So while this time the log files weren't as much help in solving the issue, it is important to remember that when you are troubleshooting an issue in Lync, take advantage of all of the information that you can, between errors in the GUI, log files/tracing, and PowerShell, in order to help you solve any issues that you run into.
Update 3/17/13 - Added information about additional update steps from KB2809243.
Just like previous versions of OCS/Lync, there are two methods to update the servers with OCS/Lync cumulative updates. You can use Microsoft Update/WSUS or you can use LyncServerUpdateInstaller.exe. Both ways accomplish the same thing, but what I find is that a lot of customers who use the Microsoft Update/WSUS method forget to then go back and apply any database updates that are needed. This blog post focuses on the LyncServerUpdateInstaller.exe method, as I prefer using it over the Microsoft Update/WSUS method:
Installing Standard Edition Server Cumulative Updates
To apply the latest cumulative updates to a Standard Edition Server, all you need to do is run LyncServerUpdateInstaller.exe and click on Install Updates:
The installer will detect what Lync services have been installed on the server and will display whether or not the latest update has been applied. Once the updates have been installed, restart the server if prompted to do so and then skip down to the "Installing Lync Database Updates" at the bottom of this article.
Installing Enterprise Edition Pool Front End Server Cumulative Updates
With the release of the Lync Server 2013 Cumulative Updates, the process for updating Front End Servers in an Enterprise Edition Pool has changed slightly. Most of the changes have to do with the move to using Windows Fabric to replicate data between the Front End Servers in an Enterprise Edition Pool. With the introduction of Windows Fabric a couple of other concepts were also introduced, User Groups and Upgrade Domains. Both are created and managed by Windows Fabric automatically. You can read more about these new features in the Lync Server 2013: Windows Fabric & User Groups blog post. Because of these new concepts in Lync Server 2013, you will need to update your Front End Servers one at a time, making sure that services are fully restored on that server before you move on to the next Front End Server in the pool in order to make sure that you maintain quorum and at least one copy of all of the user groups. The flow chart below, from the Upgrade or Update Front End Servers TechNet article, walks through the process:
Running Get-CsPoolUpgradeReadinessState should return something similar to the following output:
If the cmdlet returns True for IsReadyForUpgrade for the server you are going to update, you can then run LyncServerUpdateInstaller.exe and apply the necessary updates on the Front End Server:
This process is the same as updating a Standard Edition Server. Once the updates have been installed, restart the server if prompted to do so. Once the server has been restarted, make sure that all of the services have returned to the running state and then run the Get-CsPoolUpgradeReadinessState cmdlet again and repeat the process until all of the Front End Servers in the pool have been updated. You can then skip to the "Installing Lync Database Updates" at the bottom of this article.
Installing Lync Database Updates
Also like previous version of OCS/Lync there Lync database updates that need to be applied. The steps are detailed in the "Step 2: Apply the back end database updates" section in KB2809243. You apply the update by running the following PowerShell cmdlet on one Front End Server in each Enterprise Edition Pool and all Standard Edition Servers in your environment:
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn FEBE.FQDN -Verbose
Additional Update Steps
Also make sure that you follow the steps in sections "Step 3: Enable the Mobility service" and "Step 4: Enable the Unified Communications Web API" in KB2809243.
Installing Updates on Other Lync Server 2013 Servers
To apply the latest cumulative updates on other Lync Server 2013 servers in your environment, just run LyncServerUpdateInstaller.exe and click on Install Updates.
Update 4/2/13 - Updated for release of Android client.Update 3/12/13 - Updated for release of iOS client.
With the release of the Lync Server 2013: February 2013 Cumulative Updates, additional features are available with Lync mobility. In order to take advantage of these new features, you will need to install the Lync 2013 version of the mobile client for the respective mobile platform. The Lync 2013 mobile client will be released for Windows Phone, iOS, and Andriod through their respective marketplace. The time and availability of the mobile apps will vary between each marketplace.
There are a bunch of new features in both the Lync 2013 mobile client and the server. The list below has some of the important changes:
Deployment Considerations
Since A/V is now supported over 3G/4G, or Wi-Fi the Edge Server plays a larger role in mobility deployments. In the diagram below, you can see that the mobile client will still send signaling information via the Reverse Proxy, but it will now send media via the A/V Edge interface on the Edge Server:
When in co-existence with Lync Server 2010, your Lync autodiscover URLs can still resolve to a Lync Server 2010 Front End Server or Director. The Lync autodiscover service will be return the correct external web services FQDN for your user based on your homed pool. The media traffic from the Lync 2013 mobile client can also use a Lync Server 2010 Edge Server.
Windows Phone Client Interoperability
From the table above, you can see that the Lync 2013 Windows Phone mobile client can only be installed on Windows Phone 8 and can only connect if the user is homed on a Lync Server 2013 pool that has the cumulative update installed. If you try to sign in to a Lync Server 2010 Front End Server or a Lync Server 2013 Front End Server without the cumulative update using the Lync 2013 mobile client you will see the following error message:
Error: "You can't sign in with this version of Lync. Please install Lync 2010."
iOS and Android Client Interoperability
The Lync 2013 iOS client has been released for iPhone and iPad. It is now available in the iTunes store. You will need to be running iOS 6.0 or later. Keep in mind that for this client to work you will need to be homed on a Lync Server 2013 Standard Edition Server or Enterprise Edition Pool with at least the Lync Server 2013: February 2013 Cumulative Updates installed. Also the Lync 2013 Android client has been released. It is now available in the Google Play store. The list of supported Android phones is listed in KB2829747.
I ran across this today with a customer. We were setting up Exchange UM to connect to Lync and while that was working just fine, users could leave voicemail messages for other users, the email messages weren't being delivered to the user's mailbox. Looking at the Application Event Log on the UM Server we say the following error message:
Log Name: ApplicationSource: MSExchange Unified MessagingDate: 2/11/2013 11:22:08 AMEvent ID: 1423Task Category: UMCoreLevel: ErrorKeywords: ClassicUser: N/AComputer: SERVERNAMEDescription:The Unified Messaging server encountered an error while trying to process the message with header file "C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\voicemail\8e22c540-bc77-4f72-9a60-758a04a1522b.txt". Error details: "Microsoft.Exchange.Net.ExSmtpClient.TlsApiFailureException: A TLS API failure occurred. Error = 0x80090301
The TLS API failure was being cause because they had applied KB931125 to the server. You can read more about this issue from the Windows Server Blog. Unfortunately this causes the Trusted Root Certificate store to grow rather large and thus causes the TLS API failure. The fix is to either delete any unneeded root certificates or run the Fix it from KB2801679.
Update 2/26/14 - This issue has been resolved with the release of Service Pack 1 for Office 2013. You can get more information here.
I ran across this while testing an issue a reader of my blog posted in the comments of an article I wrote about the Lync Basic 2013 client. They had mentioned that when a user using the Lync Basic 2013 client was set to A/V disabled the options for A/V were still presented in the client. In my testing I found this to be true and in fact the options were not only presented to the user, but A/V wasn't blocked if the user tried to initiate an A/V call to another user. For my testing I was using version 15.0.4420.1017 of the Lync Basic 2013 client. You can see in the screen shot below that even though the user is set to A/V disabled in Lync, the Phone tab and the Call Forwarding options still appear and the user is actually in a call with another user:
In addition, the options for starting an A/V call with another user are available:
Also, when looking at the A/V disabled user's presence from another client, you can see that they show as "Video Capable", even though they should be disabled for video:
If you compare this to the same user signed into the Lync 2013 client, you can see that the Phone tab and the Call Forwarding options are removed, as expected:
Also, the options for initiating an A/V call are removed as well:
So how does the Lync client know what features to make available when the user signs in? The answer is through information received by the client via in-band provisioning. The Lync client sends out a SIP SUBSCRIBE requesting provisioning information:
SUBSCRIBE sip:wcooper@test.deitterick.com SIP/2.0
...
Content-Type: application/vnd-microsoft-roaming-self+xml
The response is a SIP/2.0 200 OK and contained in the response is the setting we're interested in:
<telephonyMode>NoAudioVideo</telephonyMode>
The telephonyMode setting can contain a couple of different values, depending on what the user is configured for:
It appears that currently the Lync Basic 2013 client is ignoring this setting and is allowing the user to initiate A/V sessions whether the user is enabled to do so or not.
Update 1/30/13 - Lync Server 2010: January 2013 Cumulative Updates have been released which fixes this issue. You can download the latest updates here: http://support.microsoft.com/?kbid=2791665.
I ran into this issue at a customer the other day. They are in the process of migrating from OCS 2007 R2 to Lync Server 2010. They discovered that after moving some pilot users to Lync Server 2010, if a user tried to join a Live Meeting meeting that one of the pilot users had created either before they were moved to Lync Server 2010 or before the Lync 2010 client was installed by using the Conferencing Add-in for Microsoft Office Outlook, they would get the following error:
Live Meeting cannot connect to the version of server. To connect using Communicator instead, click OK. To cancel out of joining the meeting, click Cancel.
Currently this is being caused by an issue in Lync Server 2010 after applying the Cumulative updates for Lync Server 2010: October 2012. If the user clicks the OK button, the Lync Server 2010 join launcher will launch and use the Lync Web App or the Lync Attendee client to connect to the meeting. If the user already has the Lync 2010 client, after they click the OK button, the Lync 2010 client will open and connect to the meeting. Once the user joins with a Lync client (Lync Web App, Lync Attendee, or Lync 2010), they can participate in the meeting. The clients will have a reduced set of features available during the meeting. Depending on the client used, IM, Audio, Video, Desktop/Application Sharing, and recording are available.
I've run into this issue a couple times when deploying Lync Server 2013 in my lab and at customer sites. Topology Builder makes it very easy to deploy your Lync servers quickly, but in Lync Server 2013, there's one gotcha you need to be aware of when initially deploying multiple Lync Server 2013 servers at once. And it has to do with the OAuth certificate used in Lync Server 2013. I've previously written about OAuth and its role in Lync Server 2013 here: OAuth Certifcate in Lync Server 2013.
The gotcha is that you need to have the OAuthTokenIssuer certificate assigned before you can complete Step 3 in the Deployment Wizard and proceed to starting services. If this is the first set of Lync Server 2013 servers you're deploying, the OAuthTokenIssuer certificate was replicated to the CMS when you assigned it to the first Lync Server 2013 server. The problem arises if you have already completed Step 1 in the Deployment Wizard on the other Lync Server 2013 servers that require the OAuthTokenIssuer certificate.
Part of Step 1 in the Deployment Wizard is to connect to the CMS and grab a copy of the current topology. This copy of the topology doesn't yet have the OAuthTokenIssuer certificate in it.
When you get to Step 3 in the Deployment Wizard, you will see that the OAuthTokenIssuer certificate hasn't replicated to this Lync server...and it won't. This server is looking a the local copy of the CMS that was imported during Step 1. That means that in order for this server to know that there's an OAuthTokenIssuer certificate in the CMS that it's supposed to use, you need to get the updated topology replicated to this server. There are two ways to accomplish this. The first way is to use the Export-CsConfiguration and Import-CsConfiguration with the -LocalStore parameter. The second way is to just let CMS replication happen. You will need to make sure that at least one Front End Server is operational in the pool configured to host the CMS. Then on the other Lync Server 2013 servers that need the OAuthTokenIssuer certificate replicated to it, make sure that the Lync Server Replica Replicator Agent service is started:
Once the Lync Server Replica Replicator Agent service is started, you will be waiting for replication to happen and the following events to appear in the Lync Server event log:
Once you see Event ID 3038, the CMS has replicated the OAuthTokenIssuer certificate to the server. You can also check Get-CsManagementStoreReplicationStatus and make sure that the server is up-to-date:
UpToDate : TrueReplicaFqdn : LAB-LS15-DIR1.lab.deitterick.comLastStatusReport : 11/24/2012 8:15:36 PMLastUpdateCreation : 11/24/2012 8:08:05 PMProductVersion : 5.0.8308.0
If you refresh the Certificate Wizard or run Step 3 from the Deployment Wizard again, you will now see the OAuthTokenIssuer certificate assigned to the server:
You can now complete Step 3 and continue on with Step 4 in the Deployment Wizard.
While Topology Builder makes it very easy to deploy your entire Lync Server 2013 environment in one shot, you just need to be aware of how and when the OAuthTokenIssuer certificate is replicated to your Lync Server 2013 servers.
With the release of Lync Server 2013, there are two versions of the Lync 2013 client available:
What's the difference between the two?
Lync Basic 2013 provides all the basic functionality that’s available in the full version of Lync (Lync 2013). However, if you want to use any of the following features, you will need to upgrade to Lync 2013:
You can find more information on which specific features are supported in each client in the Client Comparison Tables TechNet article.
Where can I download the Lync 2013 clients?
Lync Basic 2013 is available on the Microsoft Download Center and comes in two versions:
Lync 2013 is available via the Microsoft Volume Licensing Service Center for customers with a Volume Licensing agreement.
When requesting certificates in your Lync Server 2013 environment, you will notice that there is a new certificate type that needs to be requested, OAuthTokenIssuer. What is OAuth and what do we use it for in Lync Server 2013?
OAuth (Open Authorization) is a protocol for server-to-server authentication and authorization. With OAuth, user credentials and passwords are not passed from one computer to another. Instead, authentication and authorization is based on the exchange of security tokens; these tokens grant access to a specific set of resources for a specific amount of time. Lync Server 2013 supports three server-to-server authentication scenarios. With Lync Server 2013 you can:
You can read more about OAuth and it's uses in the Managing Server-to-Server Authentication (Oauth) and Partner Applications TechNet article.
As you complete the request for the OAuthTokenIssuer certificate and view the certificate, you'll see that it looks something similar to:
One important thing to note about the OAuthTokenIssuer certificate, that is different from other certificates in Lync Server 2013, is that the OAuthTokenIssuer certificate is a global certificate:
So what does that mean? It means that the same OAuthTokenIssuer certificate needs to be used by all of the Lync Server 2013 servers. In order to assure this, when you assign this certificate, it is replicated via the CMS and is assigned to all of the Lync Server 2013 servers that require OAuth. If you look in the directory where the Lync Server 2013 logs are stored (C:\Users\<username>\AppData\Local\Temp), you will see a log file similar to:
ReplicateCMSCertificates-[2012_07_31][11_49_20].html
If you open that log file it will look something similar to:
If you wait for replication to succeed and then look at another Lync Server 2013 server, you will see that the OAuthTokenIssuer certificate has been replicated and assigned to that server:
So what happens if I request an OAuthTokenIssuer certificate on multiple servers? In that case whichever certificate is replicated to the CMS last will be used by all of the Lync Server 2013 servers.
So when requesting the OAuthTokenIssuer certificate in Lync Server 2013, remember to only request it once and sit back and let CMS replication take care of the rest!
Update 4/8/14 - Updated prerequisites for Windows Server 2008 R2.Update 1/12/13 - Updated with additional information.Update 11/10/13 - Updated with links to updates for Office Web Apps Server.Update 3/18/13 - Updated for RTM of Lync Server 2013.Update 11/14/12 - Updated for RTM of Office Web Apps Server.
The Office Web Apps Server is a required role when deploying Lync Server 2013. By default when you add conferencing to the pool, you'll notice that in Topology Builder, you will be required to associate the Standard Edition Server or Enterprise Edition pool with an Office Web Apps Server, either new or existing:
However, you can deselect the check box and continue along without associating the Office Web Apps Server. This is not recommended, as you won't be able to use any features that rely on the Office Web Apps Server.
Defining a New Office Web Apps Server is easy...all you need is the FQDN of the server:
Once the Office Web Apps Server is defined, Topology Builder will let you continue:
So what is the advantage of using an Office Web Apps Server? From the Overview of Office Web Apps Server TechNet article:
How Lync Server 2013 uses Office Web Apps Server for viewing PowerPoint broadcasts
In Lync Server 2010, PowerPoint presentations are viewed in one of two ways. For users who run Lync 2010, PowerPoint presentations are displayed by using the PowerPoint 97-2003 format and they are viewed by using an embedded copy of the PowerPoint viewer. For users who run Lync Web App, PowerPoint presentations are converted to dynamic HTML files then viewed by using a combination of the customized DHTML files and Silverlight. Although generally effective, this approach did have some limitations:
To help address these issues, and to improve the overall experience of anyone who presents or views PowerPoint presentations, Lync Server 2013 uses Office Web Apps Server to handle PowerPoint presentations. Among other advantages, this new approach allows the following capabilities:
Now that you know what the Office Web Apps Server does, how do you go about preparing to install it? From the Deploy Office Web Apps Server TechNet article:
Installing Required Roles and Services
Windows Server 2008 R2 and Windows Server 2012/2012 R2 have slightly different prerequisites. Be sure to install the correct prerequisites for your operating system.
To prepare a server that runs Windows Server 2008 R2:
Install the following software:
Next, open the Windows PowerShell prompt as an administrator and run the following sample commands to install the required roles and services:
Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support
To prepare a server that runs Windows Server 2012/2012 R2:
Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-WCF-HTTP-Activation45
Installing Updates
Make sure that you also install any updates to the Office Web Apps Server(s). You will need to download and install the updates listed here: Update center for Office, Office servers, and related products.
Certificates
When creating the certificate request the Office Web Apps Farm make sure that you include SAN entries for the FQDNs of all of the servers in the farm:
If you don't include all of the Office Web App Server 2013 server FQDNs in the SAN of the certificate, you may see the issues here.
Once you have the Office Web Apps Server installed, updated, and configured, the Lync Server 2013 Front End Servers will discover the Office Web Apps Server and you will see the following events in the Event Log on the Front End Servers:
What is the User Experience if you Don't Deploy an Office Web Apps Server?
So what happens you define, but haven't yet deployed an Office Web Apps Server in your environment? The first thing you'll notice is that the Lync Server 2013 Front End Servers will throw the following error in the Event Log:
Office Web Apps Server (WAC) discovery failed, PowerPoint content is disabled.
Attempted Office Web Apps Server discovery Url: https://TEST-OWAS.test.deitterick.com/hosting/discovery/Received error message: The remote name could not be resolved: 'test-owas.test.deitterick.com'The number of retries: 2, since 8/7/2012 10:38:06 PM.Cause: Office Web Apps Server may be unavailable or network connectivity may have been compromised.Resolution:Check HTTPS connectivity from this box to the Office Web Apps Server deployment using the discovery Url.
Also, clients will notice the following error message when they try to share a PowerPoint presentation:
As you can see, the Office Web Apps Server will be an important component in your Lync Server 2013 deployments! Make sure to plan and include it when installing/migrating to Lync Server 2013.
Backup registrar functionality works in Lync Server 2013 the same way that it did in Lync Server 2010. This means that the client is informed of it's backup registrar via a SIP/2.0 301 Redirect request to Home Server. This response will contain the user's primary registrar and their backup registrar:
Contact: <sip:BETA-LS15-SE1.beta.deitterick.com:5061;transport=TLS>;q=0.7Contact: <sip:BETA-LS15-SE2.beta.deitterick.com:5061;transport=TLS>;q=0.3
The backup registrar information is not cached in the EndpointConfiguration.cache file on the client just like in Lync Server 2010 so the client will need this information each time in order to be able to contact the user's backup registrar. After the initial logon, the user's primary registrar will be cached in the EndpointConfiguration.cache file and all subsequent logons will read from that file. As long as the user's primary registrar is up and accepting connections, the client will register directly with the user's primary registrar, and no SIP/2.0 301 Redirect request to Home Server will be returned to the client.
With Lync Server 2013 introducing paired pools as the disaster recovery measure, it is again important that users be able to locate their backup registrar and sign in. This means that if you are going to be setting up paired pools in Lync Server 2013 make sure to use multiple SRV records that utilize different priorities:
_sipinternaltls._tcp.beta.deitterick.comPriority: 0Weight: 0Port: 5061Target: BETA-LS15-SE1.beta.deitterick.com
_sipinternaltls._tcp.beta.deitterick.comPriority: 10Weight: 0Port: 5061Target: BETA-LS15-SE2.beta.deitterick.com
This way clients will be able to locate their backup registrar and sign in in the event that the user needs to use their backup registrar. You can find more information on best practices in the Best Practices for Pairing Front End Pools TechNet article.
I was testing out the new paired pool functionality in Lync Server 2013 in my lab when I ran into an interesting issue. You can find more information about paired pools in the Planning for Front End Pool Pairing TechNet article. After selecting the backup pool for my primary pool in Topology Builder, when I went to publish the topology, I got the following error:
Error: Script failed when installing "CentralMgmtStore" on "BETA-LS15-SE1.beta.deitterick.com\rtc". For details, see the following log file: "C:\Users\Administrator.BETA\AppData\Local\Temp\Create-CentralMgmtStore-BETA-LS15-SE1.beta.deitterick.com_rtc-[2012_08_01][12_13_34].log"
Looking at the log file mentioned in the error message:
****Creating DbSetupInstance for 'Microsoft.Rtc.Common.Data.XdsDatabase'****Initializing DbSetupBaseParsing parameters...Found Parameter: SqlServer Value BETA-LS15-SE1.beta.deitterick.com\rtc.Found Parameter: SqlFilePath Value C:\Program Files\Common Files\Microsoft Lync Server 2013\DbSetup.Found Parameter: Publisheracct Value BETA\RTCUniversalServerAdmins;RTC Local Administrators.Found Parameter: Replicatoracct Value BETA\RTCUniversalConfigReplicator;RTC Local Config Replicator.Found Parameter: Consumeracct Value BETA\RTCUniversalReadOnlyAdmins;RTC Local Read-only Administrators.Found Parameter: Role Value master.Trying to connect to Sql Server BETA-LS15-SE1.beta.deitterick.com\rtc. using windows authentication...Sql version: Major: 11, Minor: 0, Build 2100.Sql version is acceptable.Validating parameters...DbName xds validated.SqlFilePath C:\Program Files\Common Files\Microsoft Lync Server 2013\DbSetup validated.DbFileBase xds validated.DbPath is not specified, using default.Default DB Path not found. Trying Master DB Path.Default DB Path is c:\Program Files\Microsoft SQL Server\MSSQL11.RTC\MSSQL\DATA.DbPath c:\Program Files\Microsoft SQL Server\MSSQL11.RTC\MSSQL\DATA validated.Effective database Path: \\BETA-LS15-SE1.beta.deitterick.com\c$\Program Files\Microsoft SQL Server\MSSQL11.RTC\MSSQL\DATA.LogPath is not specified, using default.Default Log Path not found. Trying Master DB Path.Default Log Path is c:\Program Files\Microsoft SQL Server\MSSQL11.RTC\MSSQL\DATA.LogPath c:\Program Files\Microsoft SQL Server\MSSQL11.RTC\MSSQL\DATA validated.Effective Log Path: \\BETA-LS15-SE1.beta.deitterick.com\c$\Program Files\Microsoft SQL Server\MSSQL11.RTC\MSSQL\DATA.Setting security for database xds.Can not update database xds since the database state is not up to date. Current database state is DbState_DoesNotExist.
You can see that the xds database doesn't exist. Unfortunately Topology Builder doesn't create the database for you. The backup pool I was selecting was already installed and running, so this database didn't exist on that server. So in order to fix this issue, you will need to run the following PowerShell cmdlet:
Install-CsDatabase -CentralManagementDatabase -SQLServerFQDN <FQDN of your SQL Server> -SQLInstanceName <name of instance>
This will create a blank xds database on the backup pool. This is the same cmdlet that you would run if you were following the steps to move the CMS to another pool. After the database is created, you can go ahead and publish the topology again. This time it will complete successfully and you will have configured paired pools in Lync Server 2013.
Lync Server 2013 now supports the ability to use SQL mirroring to provide high availability for the Lync Server 2013 back end. You can learn more about SQL mirroring in Lync Server 2013 from the Back End Server High Availability TechNet article. This post talks about an issue I ran into while attempting to setup SQL mirroring in my lab when SQL Server wasn't running under a service account. The solution is slightly different depending on which version of SQL Server you are running.
You use Topology Builder to configure SQL mirroring for Lync Server 2013. When you publish the topology after setting up SQL mirroring, you will see the following dialog box:
SQL mirroring requires a file share so that it can place backups of the databases there for the mirror server to access. You need to select the mirror store and click on Settings in order to define the file share location:
Take particular note of the permissions required.
You can see from above that the step failed. Looking at the log, you can see the following:
Error setting up mirroring or witness for database rtcxds: Microsoft.Rtc.Management.Deployment.MirrorDatabaseException: Cannot backup database "rtcxds". Verify that the primary SQL Server instance is available and that the account running the primary SQL Server instance has write access to the specified file share. Exception: Microsoft.SqlServer.Management.Smo.FailedOperationException: Backup failed for Server 'BETA-SQL1.beta.deitterick.com'. ---> Microsoft.SqlServer.Management.Common.ExecutionFailureException: An exception occurred while executing a Transact-SQL statement or batch. ---> System.Data.SqlClient.SqlException: Cannot open backup device '\\BETA-SQL2.beta.deitterick.com\SQLMirrorBackup\DbDataBackup-rtcxds-BETA-SQL1.beta.deitterick.com-[2012_07_29][03_11_33].bak'. Operating system error 5(Access is denied.). BACKUP DATABASE is terminating abnormally. at Microsoft.SqlServer.Management.Common.ConnectionManager.ExecuteTSql(ExecuteTSqlAction action, Object execObject, DataSet fillDataSet, Boolean catchException) at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String sqlCommand, ExecutionTypes executionType) --- End of inner exception stack trace --- at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(String sqlCommand, ExecutionTypes executionType) at Microsoft.SqlServer.Management.Common.ServerConnection.ExecuteNonQuery(StringCollection sqlCommands, ExecutionTypes executionType) at Microsoft.SqlServer.Management.Smo.ExecutionManager.ExecuteNonQuery(StringCollection queries) at Microsoft.SqlServer.Management.Smo.BackupRestoreBase.ExecuteSql(Server server, StringCollection queries) at Microsoft.SqlServer.Management.Smo.Backup.SqlBackup(Server srv) --- End of inner exception stack trace ---
So we're getting an access denied error when trying to connect to that share. We know from the dialog box above that we need to give out rights to the file share:
The primary SQL instance must have write permission to the file share and the mirror SQL instance must have read permission to the file share.
That makes sense, but in this case we're not using a service account for the SQL instance to run under, so what exactly do we give rights to? This is where the process differs depending on what version of SQL Server you are running.
SQL Server 2008 R2
When installing SQL Server 2008 R2 you have the option to run the SQL Server service under NETWORK SERVICE. The solution in this case is fairly simple. You just need to add NETWORK SERVICE with Read/Write permissions to the file share that you defined:
After you add NETWORK SERVICE, you can run Install Database from Topology Builder and the process will complete successfully:
SQL Server 2012
The default account that SQL Server 2012 runs under is slightly different than in previous versions of SQL Server. The installer defaults to using "NT Service\MSSQLSERVER" if you are running the default instance, or "NT Service\MSSQL$InstanceName" if you are using a named instance of SQL. You can read more about the new account types in the Configure Windows Service Accounts and Permissions TechNet article. Checking the Share Permissions for the file share that we created, you can see that Everyone has full access:
But looking at the file permissions, you can see that only SYSTEM and Administrators have access:
So we need to give rights to the folder we created so that both SQL servers can access it, but since SQL is running under a virtual account, what do we give rights to? First, I wanted to verify that the SQL Server was actually trying to make a connection using the virtual account. Even though I was running Topology Builder and publishing the topology from the Lync Server, the configuration of SQL mirroring happens on both SQL Servers. I took a Process Monitor trace on the primary SQL Server and found the access denied event when it tried to place the SQL database backups in the shared folder:
Looking at the Process tab, you can see that the user account was "NT Service\MSSQLSERVER":
Unfortunately, unlike SQL Server 2008 R2, you can't just assign "NT Service\MSSQLSERVER" access to the file share and be finished. However, there is some good information listed in the Configure Windows Service Accounts and Permissions TechNet article. Specifically:
Services that run as virtual accounts access network resources by using the credentials of the computer account in the format <domain_name>\<computer_name>$.
So the SQL Server service will use the computer account when it needs to access network resources. Because of that, there are 3 different ways that you can assign rights, depending on where the file share is located. The first way is to add Everyone Full control to the folder:
This is the easiest way and will allow both SQL Servers access to the file share. It's also a bit overkill, since it opens up more access than is needed. The second option is to add both computer accounts Full control to the folder:
This option only works if the file share is not on one of the SQL Servers. That is because the computer account is only used in this case to access resources that aren't on the local computer. And in this example, that's not true for BETA-SQL2, since the file share is located on that computer. The last option is to add the computer account of the SQL Server that doesn't have the file share on it and the "NT Service\MSSQLSERVER" account of the SQL Server that does have the file share on it:
This allows the SQL Server without the file share on it to use the computer account to gain access to the file share and it allows the SQL Server service from the computer that does have the file share on it to have access as well. Depending on which option you choose, after you add the necessary account(s), you can run Install Database from Topology Builder and the process will complete successfully:
So if you are going to be setting up SQL mirroring for Lync Server 2013 and you are not using a service account to run SQL Server, make sure that you give the necessary account(s) the rights that they need to connect to the file share.
I was installing Lync Server 2013 Preview in my lab and while running Step 1 from the Deployment Wizard I got the following message:
I found the Additional Software Requirements TechNet article (http://technet.microsoft.com/en-us/library/gg398686(v=ocs.15)) that lists the additional software that needs to be installed with Lync. I found Windows Identity Foundation and the link in the TechNet article directed me to download the software from here:
http://go.microsoft.com/fwlink/p/?linkId=204657
After downloading the software and running the installer on my Windows Server 2012 Release Candidate Front End Server, I got the following error message:
Installer encountered an error: 0x80096002
The certificate for the signer of the message is invalid or not found.
After doing a little research, I discovered that Windows Identity Foundation is built into Windows Server 2012 Release Candidate as an additional Feature that you can add via Server Manager:
After selecting Windows Identity Foundation 3.5 from the Add Roles and Features Wizard, I clicked Next and then Install. Once the installation wizard completed I ran Step 1 from the Lync Server 2013 Preview again and this time Windows Identity Foundation passed the prerequisite check:
So if you are installing Lync Server 2013 Preview on Windows Server 2012 Release Candidate, make sure that you add Windows Identity Foundation from the Add Roles and Features Wizard!
I went to look for the client uccapilog file, but it wasn't in the location I was expecting. In previous versions of Communicator and Lync 2010, the client tracing folder was stored in:
C:\Users\<username>\Tracing
In Lync 2013, the client tracing folder in now stored in the following location:
C:\Users\<username>\AppData\Local\Microsoft\Office\15.0\Lync\Tracing
Update 3/17/13 - Added information about .NET 3.5 installation error on Windows Server 2012.Update 9/19/12 - Added HTTP Activation for Windows Server 2012.Update 7/20/12 - Added Dynamic Content Compression and additional information for Windows Server 2012.
The following IIS role services must be installed before attempting to install this product:
To make installing the role services easier, here are the PowerShell commands. For Windows 2008 R2 SP1, open a PowerShell command window as Administrator and run the following commands:
Import-Module ServerManagerAdd-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Http-Errors,Web-Asp-Net,Web-Http-Logging,Web-Log-Libraries,Web-Http-Tracing,Web-Windows-Auth,Web-Client-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Web-Scripting-Tools
For Windows Server 2012/2012 R2, open a PowerShell command window as Administrator and run the following commands:
Import-Module ServerManagerAdd-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Http-Errors,Web-Asp-Net,Web-Asp-Net45,Web-Http-Logging,Web-Log-Libraries,Web-Http-Tracing,Web-Windows-Auth,Web-Client-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Web-Scripting-Tools,NET-WCF-HTTP-Activation45
Note: On Windows Server 2012/2012 R2, you may get the following error message when you try to run the Add-WindowsFeature cmdlet above:
Add-WindowsFeature : The request to add or remove features on the specified server failed.Installation of one or more roles, role services, or features failed.The source files could not be downloaded.Use the "source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see http://go.microsoft.com/fwlink/?LinkId=243077. Error: 0x800f0906
This is because the .NET Framework 3.5 is not included in Windows Server 2012/2012 R2 and needs to be either downloaded from Windows Update or you need to provide the location to the Windows Server 2012/2012 R2 installation media. You can read more about this in the Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012 KB article. To provide the location of the Windows Server 2012/2012 R2 installation media, run the Add-WindowsFeature cmdlet from above and add the -Source parameter with the location of the Windows Server 2012/2012 R2 installation media, i.e -Source D:\sources\sxs.
This week I ran into two interesting issues, both around MRAS and the clients displaying Limited External Calling. So what is MRAS anyway? MRAS (Media Relay Authentication Service) is a service on the Edge Server that is responsible for providing credentials to clients in order for them to be able to request ports and establish media sessions through the Edge Server. Without these credentials, clients will not be able to include Edge Server candidates in their candidate list when trying to establish a media session.
Clients will send a request for MRAS credentials every time the user signs in. When the user signs in, the client will send a SIP SERVICE message to the Front End Server requesting MRAS credentials. This request includes the user's SIP address and whether or not they are on the intranet or internet, among other things. You can see a normal request below:
Start-Line: SERVICE sip:TEST-LS14-EDGE1.dmz.test.deitterick.com:5062;grid SIP/2.0From: "William Cooper"<sip:wcooper@test.deitterick.com>;tag=6392822386;epid=e114d373a8To: <sip:TEST-LS14-EDGE1.dmz.test.deitterick.com@test.deitterick.com;gruu;opaque=srvr:MRAS:tmsOHGdb9lGxCPJSi2p6eAAA>CSeq: 1 SERVICECall-ID: 3ca1e573619f4be4975e6cd6ec1f44bdRecord-Route: <sip:TEST-LS14-SE1.test.deitterick.com:5061;transport=tls;opaque=state:T;lr>;tag=F0801F2A7EAD2D0381EEE38345CE6E66Via: SIP/2.0/TLS 172.16.7.6:60353;branch=z9hG4bK58E6CA87.914C06A09A4174A8;branched=FALSEMax-Forwards: 69ms-application-via: SIP;ms-urc-rs-from;ms-server=TEST-LS14-SE1.test.deitterick.com;ms-pool=TEST-LS14-SE1.test.deitterick.com;ms-application=ad894dc3-55e0-44bf-a07e-3c073aaa4a57Via: SIP/2.0/TLS 172.16.7.8:58674;ms-received-port=58674;ms-received-cid=39700Contact: <sip:wcooper@test.deitterick.com;opaque=user:epid:2L_Ol0dqJVO_R1E7cD7V_gAA;gruu>User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)Content-Type: application/msrtc-media-relay-auth+xmlContent-Length: 496ms-user-data: ms-publiccloud=FALSE;ms-federation=FALSEMessage-Body: <request requestID="3757984" version="2.0" to="sip:TEST-LS14-EDGE1.dmz.test.deitterick.com@test.deitterick.com;gruu;opaque=srvr:MRAS:tmsOHGdb9lGxCPJSi2p6eAAA" from="sip:wcooper@test.deitterick.com" xmlns="http://schemas.microsoft.com/2006/09/sip/mrasp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><credentialsRequest credentialsRequestID="3757984"><identity>sip:wcooper@test.deitterick.com</identity><location>intranet</location><duration>480</duration></credentialsRequest></request>$$end_record
The response that is returned contains the FQDN of the Edge Server or the Edge pool, the ports that the client should send requests to, and the credentials for that user. These credentials are valid for 8 hours. You can see a normal response below:
Start-Line: SIP/2.0 200 OKFrom: "William Cooper"<sip:wcooper@test.deitterick.com>;tag=6392822386;epid=e114d373a8To: <sip:TEST-LS14-EDGE1.dmz.test.deitterick.com@test.deitterick.com;gruu;opaque=srvr:MRAS:tmsOHGdb9lGxCPJSi2p6eAAA>;tag=6b04cac19CSeq: 1 SERVICECall-ID: 3ca1e573619f4be4975e6cd6ec1f44bdVIA: SIP/2.0/TLS 172.16.7.6:60353;branch=z9hG4bK58E6CA87.914C06A09A4174A8;branched=FALSE,SIP/2.0/TLS 172.16.7.8:58674;ms-received-port=58674;ms-received-cid=39700RECORD-ROUTE: <sip:TEST-LS14-SE1.test.deitterick.com:5061;transport=tls;opaque=state:T;lr>;tag=F0801F2A7EAD2D0381EEE38345CE6E66CONTENT-LENGTH: 1002CONTENT-TYPE: application/msrtc-media-relay-auth+xmlSERVER: RTCC/4.0.0.0 MRAS/2.0ms-edge-proxy-message-trust: ms-source-type=EdgeProxyGenerated;ms-ep-fqdn=TEST-LS14-EDGE1.dmz.test.deitterick.com;ms-source-verified-user=verifiedMessage-Body: <?xml version="1.0"?><response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" requestID="3757984" version="2.0" serverVersion="2.0" to="sip:TEST-LS14-EDGE1.dmz.test.deitterick.com@test.deitterick.com;gruu;opaque=srvr:MRAS:tmsOHGdb9lGxCPJSi2p6eAAA" from="sip:wcooper@test.deitterick.com" reasonPhrase="OK" xmlns="http://schemas.microsoft.com/2006/09/sip/mrasp"> <credentialsResponse credentialsRequestID="3757984"> <credentials> <username>AgAAJCFf4/sBzVDF7Q9GNmDEp0oLdfto4acI50YDy3IAAAAAOoZBWBV8je4fgGTvyKbxh7sioMY=</username> <password>k6GJX093FIYdfVlmHkGSw0Yi+lM=</password> <duration>480</duration> </credentials> <mediaRelayList> <mediaRelay> <location>intranet</location> <hostName>TEST-LS14-EDGE1.dmz.test.deitterick.com</hostName> <udpPort>3478</udpPort> <tcpPort>443</tcpPort> </mediaRelay> </mediaRelayList> </credentialsResponse></response>$$end_record
There are a few things that can cause the client to fail to get MRAS credentials. Some of those a detailed below:
Issue #1
In this issue clients were seeing the Limited External Calling icon in the Lync 2010 client:
We ran through the normal troubleshooting steps of making sure that the proper ports were open, DNS resolution was working, and certificates were trusted by both servers. Since all of that checked out, the next step was to take SIPStack tracing on the Front End Server and the Edge Server during the client login process. Reviewing the SIPStack trace from the Front End Server showed that a SIP/2.0 504 Server time-out was being returned to the client. Specifically the response contained the following:
ms-diagnostics: 1038;reason="Failed to connect to a peer server";WinsockFailureCode="10061(WSAECONNREFUSED)";WinsockFailureDescription="The peer actively refused the connection attempt";Peer="TEST-LS14-EDGE1.dmz.test.deitterick.com";Port="5062";source="TEST-LS14-SE1.test.deitterick.com"
The SIPStack trace from the Edge Server didn't show any MRAS requests. This means that whatever the issue is, it is happening before the Edge Server can receive the SIP SERVICE message. This usually points to a certificate/MTLS issue. Depending on the amount of traffic on the Front End Server(s), you can sometimes see certificate/MTLS issues during the tracing, as the log will grow extremely large relative to the amount of traffic on the server.
Looking at the error from the SIPStack trace above, we can see that the Edge Server is refusing the connection from the Front End Server. Since this is generally a certificate issue we looked at the certificates on the Front End Server again. Everything about the certificate was correct, although the one thing we did find was that there were numerous Intermediate CA certificates listed for their Issuing CA. They only had one Issuing CA in the environment, and looking at each of the certificates listed, we found that had different thumbprints. It appears that the Issuing CA was deployed multiple times with the same name, but the certificates weren't cleaned up in Active Directory. We deleted the invalid Intermediate CA certificates for their Issuing CA and tested again. This time the client was able to request MRAS credentials from the Edge Server.
Issue #2
This issue occurred on Communicator 2007 R2 clients in an OCS 2007 R2 environment. Clients were seeing the Limited External Calling icon. We confirmed that the proper ports were open, DNS resolution was working, and that certificates were trusted by both servers. We took SIPStack tracing on the Front End Server and the Edge Server. Similar to Issue #1 above, we were getting a SIP/2.0 504 Server time-out response returned to the client. It included the following:
ms-diagnostics: 2;reason="See response code and reason phrase";source="TEST-OCSR2-SE1.test.deitterick.com";HRESULT="0xC3E93C69(SIPPROXY_E_CONNECTION_FAILED)"
This time we're getting a SIPPROXY_E_CONNECTION_FAILED. The certificate chains checked out, and everything appeared to be configured correctly, yet the Front End Server would return this error message every time. I remembered a couple environments where weird things would happen if you didn't have your Edge Server(s) patched, but you had patched your Front End Server(s). I checked the patch levels on both the Front End Server and the Edge Server, and sure enough, the Front End Server was patched and the Edge Server had no patches applied. We applied the latest OCS 2007 R2 patches to the Edge Server and tested again, and this time the client was able to request MRAS credentials from the Edge Server.
These are just a couple of issues I've run across with MRAS. The important thing to remember is to check the basics and then take logging and dig into what is really going on.
I had a question from a customer the other day about how to add the firewall rules for Lync Server 2010 to the Windows Firewall after installation. Unlike in the OCS days, adding the firewall rules back to the Windows Firewall is rather simple. This issue comes up because in some environments the Windows Firewall is disabled as part of the build process. Then sometime in the future they want to start using the Windows Firewall and this is where the issue arises. There are two ways to go about disabling the Windows Firewall and both affect differently what Lync Server 2010 does during install. The first option is to just go into the Windows Firewall control panel and disable the firewall from there:
However, this leaves the Windows Firewall server running:
Which means that during the install, Lync Server 2010 will add all the firewall rules to the Windows Firewall:
So all you need to do is turn the Windows Firewall back on from the inside the Control Panel. The second way customers disable the Windows Firewall is to disable the Windows Firewall service from the Services control panel:
This means that the Windows Firewall snap-in won't even load:
In this case, during the install Lync Server 2010 won't be able to create the firewall rules. After the install, if you go back and enable the Windows Firewall service and check the snap-in, you'll see that the CS group of firewall rules is missing:
In this case, we need a way to add all of the rules back to the Windows Firewall. You could do that manually, but that would be time consuming and there's a much easier way..the Lync Server 2010 Deployment Wizard. All you need to do once you enable the Windows Firewall service is to run Step 2 from the Deployment Wizard:
This step will check the local configuration on the machine and make any necessary changes...in this case, adding the Windows Firewall rules. After running Step 2, if you check the Windows Firewall snap-in, you'll see that the CS group and all the associated firewall rules are there:
So in Lync Server 2010, adding back the firewall rules is a much easier process than before!
I got asked an interesting question by a colleague the other day...What is the best way to normalize a 5 digit range, i.e. 53574-53899? The question seems easy enough, but in reality it's slightly harder than you would think. Most people think that this will do the trick:
^([53574-53899])$
But, as you can see, this doesn't actually do what it looks like it should:
To properly normalize this range, you will need to break apart each digit:
^(53[5-8][7-9][4-9])$
This will give you the desired result that you are looking for:
So that is how you normalize number ranges using .NET regular expression, but that only answered the first part of their question. There were some additional requirements that they needed to account for:
So taking what we learned above, and accounting for all of the possibilities, you end up with something like this:
^(535[8,9][0-9]|53[6-8][1-6][0-9]|53[6-8][8,9][0-9]|53[5-8]7[4-9])$
This expression is actually capturing for the 4 different number ranges that make up the requirements. Each is separated by the pipe '|', with in .NET regular expression means 'or'.
535[8,9][0-9]
This is normalizing numbers 5358x and 5359x, where x equals a digit 0-9. This fulfills requirement #2 from above.
53[6-8][1-6][0-9]
This is normalizing numbers 53xyz, where x equals a digit 6-8, y equals a digit 1-6, and z equals a digit 0-9. This accounts for numbers outside of requirements #1 & #2 from above.
53[6-8][8,9][0-9]
This is normalizing numbers 53xyz, where x equals a digit 6-8, y equals an 8 or 9, and z equals a digit 0-9. This accounts for numbers outside of requirements #1 & #2 from above.
53[5-8]7[4-9]
This is normalizing numbers 53x7y, where x equals a digit 5-8 and y equals a digit 4-9. This fulfills requirement #1 from above.
There are lots of ways to write normalization rules and I'm sure that there are even better ways to accomplish the above, so please feel free to comment with your examples.