This post is really just a pointer for myself and anyone else perusing my blog.
Murat has compiled a list of cumulative update versions for Lync 2010 and Lync 2013 which has helped me out a few times.
http://blogs.technet.com/b/nettracer/archive/2013/07/05/lync-client-and-server-version-numbers.aspx
Enjoy!
Saturday, 18 January 2014
Thursday, 28 November 2013
Lync Centralised Logging Error
This is a real quick fix post and more of a note to remind myself than anything else.
I was working on a support case for a customer for Lync 2013 and noticed they were not using the centralised logging feature which is a really nice feature to use when you have multiple servers in the environment. I am the first to admit that I still jump in to OCSLogger when I'm after a quick trace for a specific issue but the new centralised logging is very helpful and eases the pain of multiple logging sessions.
To get back to the point of the post, I was trying to enable the "AlwaysOn" scenario using the PowerShell command: 'Start-CsClsLogging -Scenario "AlwaysOn" -Pools mypool.mydomain'.
When running this command I was getting an error 20000, Unknown Error. This had me baffled for a few minutes as this was an error I've not seen before. Nothing much comes up in a web search for this and then I remembered that I hadn't started PowerShell as an Administrator.
Run PowerShell in administrative mode and voila, the scenario starts and all is good. So just remember that 'some' tasks in Lync require this elevated Powershell prompt to succeed and if you receive a somewhat generic error, it 'could' be related to this.
I was working on a support case for a customer for Lync 2013 and noticed they were not using the centralised logging feature which is a really nice feature to use when you have multiple servers in the environment. I am the first to admit that I still jump in to OCSLogger when I'm after a quick trace for a specific issue but the new centralised logging is very helpful and eases the pain of multiple logging sessions.
To get back to the point of the post, I was trying to enable the "AlwaysOn" scenario using the PowerShell command: 'Start-CsClsLogging -Scenario "AlwaysOn" -Pools mypool.mydomain'.
When running this command I was getting an error 20000, Unknown Error. This had me baffled for a few minutes as this was an error I've not seen before. Nothing much comes up in a web search for this and then I remembered that I hadn't started PowerShell as an Administrator.
Run PowerShell in administrative mode and voila, the scenario starts and all is good. So just remember that 'some' tasks in Lync require this elevated Powershell prompt to succeed and if you receive a somewhat generic error, it 'could' be related to this.
Wednesday, 27 November 2013
Lync 2013 PowerPoint presentation fails to load when using Windows 8.1 Operating System
I haven't blogged for a while now but this issue came up this week and will start to cause problems for users as they start to migrate to Windows 8.1.
This is due to an identified issue with the Office Web Apps 2013 application.
Please note that to install this hotfix, it will be necessary to remove the Office Web Apps machine from the farm and ultimately recreate the farm once the hotfix is installed.
This example was used to update a 2 node load balanced pool with the following details:
Please see here for more information on updating OWA: http://technet.microsoft.com/en-us/library/jj966220.aspx
Issue:
This issue only affects Lync 2013 clients installed on Windows 8.1 and specifically the PowerPoint presentation sharing via Office Web Apps. When attempting to upload a slide deck for presentation, the user will be faced by a continual Loading notification eventually (if they wait that long) ending in an error:
This is due to an identified issue with the Office Web Apps 2013 application.
Workaround:
The workaround for this is to either use the Lync Web App which does not seem to be affected, even when using Internet Explorer 11 installed on Windows 8.1 or if another machine running a Windows 8 or Windows 7 with a Lync 2013 client installed is available, this will also work.Resolution:
Microsoft has released a hotfix for this issue which can be downloaded here: http://support.microsoft.com/kb/2837634/en-usPlease note that to install this hotfix, it will be necessary to remove the Office Web Apps machine from the farm and ultimately recreate the farm once the hotfix is installed.
This example was used to update a 2 node load balanced pool with the following details:
- Node 1 name - OwaNode1.lynctest.com
- Node 2 name - OwaNode1.lynctest.com
- Farm Name - officewebapps.lynctest.com
- Log in to OwaNode1.lynctest.com with an administrative account
- Launch PowerShell
- Run the command 'Remove-OfficeWebAppsMachine'
- Install the patch KB287634
- Reboot the server and log in
- Set up a new farm on the node using a command:
- 'New-OfficeWebAppsFarm -InternalURL 'https://officewebapps.lynctest.com' -ExternalURL 'https://officewebapps.lynctest.com' -CertificateName OWACertFriendlyName'
- Log in to OwaNode2.lynctest.com with an administrative account
- Launch PowerShell
- Run the command 'Remove-OfficeWebAppsMachine'
- Install the patch KB287634
- Reboot the server and log in
- Join the machine to the farm using the command:
- New-OfficeWebAppsMachine –MachineToJoin 'OwaNode1.lynctest.com'
Please see here for more information on updating OWA: http://technet.microsoft.com/en-us/library/jj966220.aspx
Wednesday, 27 June 2012
Microsoft Lync Server 2010 Installation Failure: Error code -2068643839
I recently ran in to an installation issue deploying a Lync Standard Edition server. The server failed to install SQL Express instance prerequisite with error code -2068643839. After some research and various attempts to get SQL installed, I found that this particular error is a known issue for SQL 2008, whereby if the account used for installing SQL or in this instance SQL Express, is not granted the 'Debug Programs' user right, the installation will fail.
A default installation of Windows Server 2008 R2 will grant the builtin\Administrators local group the correct user right; however some busiensses security policy will necessitate the removal of this user right.
The solution for this is to grant the installation account the user right, run the installation and then remove the user right again so as not to compromise security. To grant the user right do the following:
At this point there will be a half installed version of SQL Express on the server which needs to be removed.
Once this is done and the SQL instance is correctly installed, the Lync deployment wizard can be re-run and Lync should install correctly. The other benefit of manually installing SQL is that the binaries can be installed on to a custom partition should that be required.
A default installation of Windows Server 2008 R2 will grant the builtin\Administrators local group the correct user right; however some busiensses security policy will necessitate the removal of this user right.
The solution for this is to grant the installation account the user right, run the installation and then remove the user right again so as not to compromise security. To grant the user right do the following:
- Launch the 'gpedit.msc' MMC snapin
- Navigate to Computer > Windows Settings > Security Settings > Local Policies > User Rights Assignment
- Find the 'Debug programs' user right
- View the properties of the setting
- Click the 'Add User or Group' button
- Add the user that you are running the installtion with
- Click 'OK' all the way out
At this point there will be a half installed version of SQL Express on the server which needs to be removed.
- Uninstall the SQL instance via programs and features
- SQLEXPR_x64.exe /ACTION=Install /FEATURES=SQLEngine,Tools /INSTANCENAME=RTC /TCPENABLED=1 /SQLSVCACCOUNT="NT AUTHORITY\NetworkService" /SQLSYSADMINACCOUNTS="Builtin\Administrators" /BROWSERSVCSTARTUPTYPE="Automatic" /AGTSVCACCOUNT="NT AUTHORITY\NetworkService" /SQLSVCSTARTUPTYPE=Automatic
Once this is done and the SQL instance is correctly installed, the Lync deployment wizard can be re-run and Lync should install correctly. The other benefit of manually installing SQL is that the binaries can be installed on to a custom partition should that be required.
Wednesday, 16 March 2011
Server could not retrieve its initial configuration for a class from the WMI Provider
I recently spent a Sunday working on the above error and found very little out there on this, hence this blog post to hopefully help others finding themselves in a similar situation.
The infrastructure consisted of a Microsoft Office Communications Server 2007 R2 co-existing with a Microsoft Lync Server 2010 implementation; however this issue could affect a standard Microsoft OCS 2007 R2 deployment just as easily. The common denominator is that a pool has been recently deactivated and removed but there are still OCS pools in the forest.
Following a restart of the OCS front-end service on any remaining pool the following errors are observed in the event log. (I have only included the pertinent information for readability)
Log Name: Office Communications Server
Source: OCS WMI Consumer
Event ID: 20482
Level: Error
Description: Server could not retrieve its initial configuration for a class from the WMI Provider.
Class: MSFT_SIPTrustedServiceSetting
Cause: This can occur if the connection to Active Directory or SQL back-end database is down or if permissions to the service account are altered. Retrieval can also fail if an invalid entry is entered in the class using the UI or WMI or if corruption occurs in local WMI repository.
Resolution:
Make sure the account the service is running under has proper privileges and that connection to Active Directory or SQL back-end database is functional. Verify an identical entry does not exist as a direct federation partner or an IM service provider.
Followed by.....
Log Name: Office Communications Server
Source: OCS Server
Event ID: 12323
Level: Error
Description: Unable to initialize the protocol stack. The service has to stop.
Error code: 80070490 (Element not found. ).
Followed by.....
Log Name: Office Communications Server
Source: OCS Server
Event ID: 12326
Level: Error
Description: Failed starting the protocol stack. The service has to stop
Error code is:0x80070490 (Element not found. ).
Cause: Check the previous entries in the event log for the failure reason.
Resolution: Try restarting the server after resolving the failures listed in the previous event log entries.
The front end service fails to start; however all other services will start successfully. It seems, when the OCS front end service starts on any FE server in the forest, the service queries and validates the trusted service entries. If there are configuration issues here then the service will fail to start complaining that it cannot retrieve its initial configuration. In this particular case it was due to 2 trusted services for an OCS recording application which had the attribute 'msRTCSIP-RoutingPoolDN' pointing to the deactivated pool and thus an invalid attribute value. This was enough to cause the service to fail.
To resolve the problem, I simply set the 2 attributes to $null as I knew this application was no longer required and as such these records were also not required. It will more than likely be a different issue in each case and s care must be taken to ensure the changes you make here are not going to have other negative affects before making the changes; however you may need to simply update this attribute to point to a valid pool if the app is still in commission. It really will be a case by case judgement call.
It is important to note that by default the OCS based trusted services have the attribute 'msRTCSIP-RoutingPoolDN' set to $null and so generally decomissioning pools will be fine; however Lync pools use this attribute and they are generally pointing at themselves which again will be fine and I would not recommned changing this.
The trusted services can be found in the Microsoft\RTC Service\Trusted Services\ container, located either in the configuration partition or system partition, depending where OCS has been installed.
I manaaged to resolve my issue after being pointed to this blog post: http://ms-uc.herber.co/?p=40 and so thanks to Louis for this answer.
The infrastructure consisted of a Microsoft Office Communications Server 2007 R2 co-existing with a Microsoft Lync Server 2010 implementation; however this issue could affect a standard Microsoft OCS 2007 R2 deployment just as easily. The common denominator is that a pool has been recently deactivated and removed but there are still OCS pools in the forest.
Following a restart of the OCS front-end service on any remaining pool the following errors are observed in the event log. (I have only included the pertinent information for readability)
Log Name: Office Communications Server
Source: OCS WMI Consumer
Event ID: 20482
Level: Error
Description: Server could not retrieve its initial configuration for a class from the WMI Provider.
Class: MSFT_SIPTrustedServiceSetting
Cause: This can occur if the connection to Active Directory or SQL back-end database is down or if permissions to the service account are altered. Retrieval can also fail if an invalid entry is entered in the class using the UI or WMI or if corruption occurs in local WMI repository.
Resolution:
Make sure the account the service is running under has proper privileges and that connection to Active Directory or SQL back-end database is functional. Verify an identical entry does not exist as a direct federation partner or an IM service provider.
Followed by.....
Log Name: Office Communications Server
Source: OCS Server
Event ID: 12323
Level: Error
Description: Unable to initialize the protocol stack. The service has to stop.
Error code: 80070490 (Element not found. ).
Followed by.....
Log Name: Office Communications Server
Source: OCS Server
Event ID: 12326
Level: Error
Description: Failed starting the protocol stack. The service has to stop
Error code is:0x80070490 (Element not found. ).
Cause: Check the previous entries in the event log for the failure reason.
Resolution: Try restarting the server after resolving the failures listed in the previous event log entries.
The front end service fails to start; however all other services will start successfully. It seems, when the OCS front end service starts on any FE server in the forest, the service queries and validates the trusted service entries. If there are configuration issues here then the service will fail to start complaining that it cannot retrieve its initial configuration. In this particular case it was due to 2 trusted services for an OCS recording application which had the attribute 'msRTCSIP-RoutingPoolDN' pointing to the deactivated pool and thus an invalid attribute value. This was enough to cause the service to fail.
To resolve the problem, I simply set the 2 attributes to $null as I knew this application was no longer required and as such these records were also not required. It will more than likely be a different issue in each case and s care must be taken to ensure the changes you make here are not going to have other negative affects before making the changes; however you may need to simply update this attribute to point to a valid pool if the app is still in commission. It really will be a case by case judgement call.
It is important to note that by default the OCS based trusted services have the attribute 'msRTCSIP-RoutingPoolDN' set to $null and so generally decomissioning pools will be fine; however Lync pools use this attribute and they are generally pointing at themselves which again will be fine and I would not recommned changing this.
The trusted services can be found in the Microsoft\RTC Service\Trusted Services\ container, located either in the configuration partition or system partition, depending where OCS has been installed.
I manaaged to resolve my issue after being pointed to this blog post: http://ms-uc.herber.co/?p=40 and so thanks to Louis for this answer.
Saturday, 5 February 2011
Remote Lync Shell Shortcut
A quick post on how to create a shortcut to the Lync shell.
One of the major administrative benefits for me with Lync Server 2010 is the CSCP and the ability to run most of the day to day admin tasks from a local PC.
Lync also supports the remote shell by publishing the shell via IIS. There are many posts out there on how to create a one off session but I want to go one step further and create a shortcut to the Lync Shell.
Step 1: Create the remote shell script
One of the major administrative benefits for me with Lync Server 2010 is the CSCP and the ability to run most of the day to day admin tasks from a local PC.
Lync also supports the remote shell by publishing the shell via IIS. There are many posts out there on how to create a one off session but I want to go one step further and create a shortcut to the Lync Shell.
Step 1: Create the remote shell script
- Open your favourite text editor
- Add the line: $Credential = Get-Credential
- Add the line: $PS-Session=New-PSSession -ConnectUri https://lyncadmin.domain.com/ocspowershell -Credential $Credential -AllowRedirection
- Add the line: Import-PSSession $PSSession
- Save the file to a custom folder such as C:\Scripts for instance as LyncAdmin.ps1
Step 2: Create the shortcut
- Create a new shortcut
- Set the location as: c:\Windows\System32\WindowsPowershell\v1.0\Powershell.exe -noexit C:\Scripts\LyncAdmin.ps1
- Give it a name
- Save it to the desktop or similar
You should now be able to double click the shorcut and the script will run. This script will prompt for credentials and then load the Lync cmdlets. This method can also be used to create shortcuts to other scripts.
Enjoy!
Saturday, 11 December 2010
Merge Topology Failure, Microsoft Lync Server 2010
For a co-existence scenario using Microsoft Office Communications Server 2007 (or R2) and
Microsoft Lync Server 2010. There is a process that must be completed once the Lync CMS and first pool has been deployed. This is the merge topology process. The process is wizard driven using the topology builder and allows the user to input manual edge server details but will query AD to import the rest of the data. Part of the process completes a validation of the existing topology and objects within AD to ensure the data being merged across is clean and duplicates do not exist.
I came across this issue when attempting to merge the topology and it can be time consuming to troubleshoot.
A typical error message encountered is:
ERROR : Topology error description: "There was a problem validating the topology XML against the XSD that defines the schema."
ERROR : Topology error instances: "[ System.Xml.Schema.XmlSchemaValidationException: There is a duplicate key sequence 'urn:application:Rgs SipServer Primary Mtls' for the 'urn:schema:Microsoft.Rtc.Management.Deploy.ServiceRoles.2008:ComponentPortId' key or unique identity constraint. ][ System.Collections.Generic.List`1[System.Object] ]"
ERROR : Topology error reason: "FailedSchemaValidation"
ERROR : There were errors while creating and validating a topology.
The important entry from this error log to note is 'urn:application:Rgs SipServer Primary Mtls'
This particular entry denotes a duplicate entry for the RGS service; however the urn:application could one of a number of different entries including Cas, Caa etc
Once you know what entry you are looking for, the easiest way to find the duplicates is to run an LDAP search within ADUC. For the error above we can run a custom LDAP search across AD for the following: (msRTCSIP-TrustedServiceType=Microsoft.Rtc.Applications.Acd).
This will return a number of entries per pool all named with GUIDs. Open each one and note which pool and entry they are for looking for the duplicate entries.
Once the duplicates are identified it is then important to identify which ones are current are ones are the duplicates and although the timestamps will be different, I would recommend running a validation of that component on the pool in question and searching the logs to find out which ones are the valid current ones and which ones can be removed. There will typically be multiple entries for an Enterprise pool due to entries for the poolname and entries for the individual front end server. These should be treated as a group of entries.
Once sure of the duplicates, remove them from AD, allow time for replication and then the merge topology should succeed.
Other typical issues include:
Mis-configuration of global components within OCS
Orphaned objects (this can occur if servers have been turned off without the correct role decomissioning process being followed)
This is not a definitive list but the key to remember for troubleshooting this type of error is that the process is ensuring the configuration is clean and valid before allowing the merge to take place which can only be a good thing.
Microsoft Lync Server 2010. There is a process that must be completed once the Lync CMS and first pool has been deployed. This is the merge topology process. The process is wizard driven using the topology builder and allows the user to input manual edge server details but will query AD to import the rest of the data. Part of the process completes a validation of the existing topology and objects within AD to ensure the data being merged across is clean and duplicates do not exist.
I came across this issue when attempting to merge the topology and it can be time consuming to troubleshoot.
A typical error message encountered is:
ERROR : Topology error description: "There was a problem validating the topology XML against the XSD that defines the schema."
ERROR : Topology error instances: "[ System.Xml.Schema.XmlSchemaValidationException: There is a duplicate key sequence 'urn:application:Rgs SipServer Primary Mtls' for the 'urn:schema:Microsoft.Rtc.Management.Deploy.ServiceRoles.2008:ComponentPortId' key or unique identity constraint. ][ System.Collections.Generic.List`1[System.Object] ]"
ERROR : Topology error reason: "FailedSchemaValidation"
ERROR : There were errors while creating and validating a topology.
The important entry from this error log to note is 'urn:application:Rgs SipServer Primary Mtls'
This particular entry denotes a duplicate entry for the RGS service; however the urn:application could one of a number of different entries including Cas, Caa etc
Once you know what entry you are looking for, the easiest way to find the duplicates is to run an LDAP search within ADUC. For the error above we can run a custom LDAP search across AD for the following: (msRTCSIP-TrustedServiceType=Microsoft.Rtc.Applications.Acd).
This will return a number of entries per pool all named with GUIDs. Open each one and note which pool and entry they are for looking for the duplicate entries.
Once the duplicates are identified it is then important to identify which ones are current are ones are the duplicates and although the timestamps will be different, I would recommend running a validation of that component on the pool in question and searching the logs to find out which ones are the valid current ones and which ones can be removed. There will typically be multiple entries for an Enterprise pool due to entries for the poolname and entries for the individual front end server. These should be treated as a group of entries.
Once sure of the duplicates, remove them from AD, allow time for replication and then the merge topology should succeed.
Other typical issues include:
Mis-configuration of global components within OCS
Orphaned objects (this can occur if servers have been turned off without the correct role decomissioning process being followed)
This is not a definitive list but the key to remember for troubleshooting this type of error is that the process is ensuring the configuration is clean and valid before allowing the merge to take place which can only be a good thing.
Subscribe to:
Posts (Atom)