Category Archives: LCS
OCS 2007 R2 Schema Prep Failure “failure occurred attempting to check the schema state. please ensure active directory is reachable"
A customer called in today with an issue preparing their OCS 2007 R2 environment. The customer had previously started installation on a 2008 R2 server, and started over with a 2008 R1 server. They had only completed the Active Directory Preparations prior to starting over. The issue was when they started on the server they were unable to see the schema prep, they were receiving this error in the install GUI:
A few interesting things here, the machine is joined to the domain, I could contact all domain controllers, I could modify the schema using the schema MMC snapin. However, the OCS install run via command line or GUI would not contact active directory.
Through some quick googling I found that the installer queries the SRV records for contacting the PDC in active directory. This SRV record is:
After pointing to a DNS issue, the customer realized their server was pointing to a public DNS server, not an active directory integrated server, which did not have the SRV records needed to perform these tasks. Once the DNS server was changed, the installer read the Active Directory Preparation as Completed and you could do a proper nslookup on those SRV records
This post outlines the basic process of taking the databases offline, migrating them, mounting them in the new instance and running LCSCMD to update the pool backened.
I recently did this in a production deployment of R2 and actually found a missing step, there was also a post on the Technet forums with a user having the same issue so I figured I would post the updated process here. This may not always be the case, but a key thing to check, and what ended up being the fix in my situation was the actual pool setting in active directory.
I believe the attribute that the below command updates is msRTCSIP-BackEndServer
LCSCmd.exe /Forest /Action:UpdatePoolBackend /PoolName:<pool name> /poolbe:<SQL instance name (machine\instance name)>
When I ran through this process I found that when I opened ADSI Edit and browsed to this attribute it actually had not changed.
The DN For the pool object will be located at : CN=Poolname,CN=Pools,CN=RTC Service,CN=Microsoft,CN=System/Config Container,DC=Domain,DC=com
Again this may not always be the case but in my experience this was thef ix for the issue.
Portland, ME (July 29, 2009) – Today, Winxnet, Inc. announced the launching of their new online store, which sells Microsoft-certified telephones, headsets, and accessories. Winxnet now has one of the only web stores exclusively selling this optimized hardware.
This new online store, which is located at www.mscertified.com, targets organizations who have converted to the more cost effective Microsoft Unified Communications and provides them with a convenient and quick method of purchasing additional equipment. As the cornerstone of Microsoft’s Unified Communications, Office Communications Server is the platform for instant messaging, audio and video conferencing, and internet based telephone communications for businesses worldwide.
“We have seen organizations purchasing equipment which was not designed to work with this new cutting edge Microsoft communications suite,” said Chris Claudio, CEO of Winxnet, Inc. “Winxnet recognized the need in the marketplace for these users to find the right product which will work for them and their communications needs.”
As a Microsoft Gold Certified Partner and Voice Certified Partner, Winxnet is a leader in implementing Microsoft’s Unified Communications technology throughout New England and considers this new online store as the next step in providing complete service.
“As more of our own clients convert to Microsoft Unified Communications, we wanted to offer a place to easily purchase Microsoft-certified headsets, phones, conferencing equipment and accessories,” said Chris Claudio, CEO of Winxnet, Inc. “I am proud that our own e-commerce team designed and developed this site and that we have already seen sales since our beta launch.”
Winxnet has deployed Unified Communications throughout New England for organizations such as Stanley Works, Harvard Vanguard, Eastern Maine Healthcare Systems, Aetna, Boston Medical Center and Children’s Hospital Boston.
The new Winxnet online store features Microsoft-certified devices from leading communication manufacturers such as Jabra, Polycom, and Plantronics.
Winxnet, founded in 1999, was created to provide customer-focused IT consulting services to organizations and businesses throughout southern Maine and has grown its operations to include offices in Waltham, Massachusetts and Chattanooga, Tennessee, employing more than 30 people. Winxnet’s clientele consists of both publicly and privately held businesses across a variety of industries, including retail, professional services, healthcare, hospitality, energy, and technology in addition to both non-profit and governmental organizations. Cultivating partnerships with clients has been a cornerstone of Winxnet’s success and continues to be a top business priority moving forward.
Winxnet is a premier Microsoft Gold Certified Partner and is headquartered in Portland, Maine. For more information, please visit www.winxnet.com.
We have done many deployments that have been LCS 2005 to OCS 2007 R2 migrations, however recently we encountered our first experience where migrating the global settings from the System Container to the Configuration Container in Active Directory was requested by the customer.
This process is outlined in documentation provided by Microsoft that can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyID=23236784-508e-44c9-809d-30ff245928d8&displaylang=en
The important thing to note here is that the documentation is clearly outlined for OCS 2007 R1 to R2 migration scenarios, NOT LCS 2005 Sp1 to OCS 2007 R2 Migration Scenarios. The documentation states this works for LCS as well as OCS however, we ran into a bunch of flaws in the documentation that I will outline below with workarounds.
First off, LCS was never meant to work with the configuration container, Microsoft released an update here: http://support.microsoft.com/kb/911996 that supposedly would fix this. Basically if you had not installed that KB Update and tried to use LCSCmd to prep the forest with the /global:configuration switch it would error out with Invalid Parameters. Once you install this patch, the LCSCmd will take the /global:configuration switch and report a success. The interesting part here is that any version of LCS 2005 Sp1 Forest or Domain prep will not perform the correct functions on the Global Settings if they are stored in the configuration container and the system container at the same time. The hard thing about this is that the documentation states to wait to delete the system container information until testing all services, unfortunately this is impossible.
Here are the various issues I ran into while performing this migration. First off, the scripts do their job just as they should, the script would successfully migrate the Global Settings containers to the Configuration Container. We did however start running into some minor issues when we went to update the user DN References. We noticed the user DN references script was not making any changes and kept saying it was not complete.
We decided to check the msRTCSIP-PrimaryHomeServer setting to see if these changes had indeed been made, we viewed users in different OUs and confirmed they were pointing to the configuration data for their home server.
From here we started to panic so we decided to test if we could start the LCS Service. The LCS Service would fail to start with the error messages shown below:
When using lcserror.exe to lookup the error code provided in the last error this was the response:
In the LCS Management Console there were two pools showing up, both with the same name. One pool would have no servers and users, and the other would have all of the servers and users. This was a good way for us to confirm that all users and servers were pointing to the Configuration Container for their information. The above error states it cannot find the AD objects it needs, which still didn’t seem to make sense because it was pointing to the configuration container. When checking the objects through ADSI Edit I noticed that the global settings containers were in the correct places, however none of the proper permissions had been applied to them, this usually happens during Domain Prep, which as I had mentioned above will not work with the global settings being in the System and Configuration Container at the same time. We manually added the RTCDomain groups to the containers with the proper permissions however the services still would not start.
Microsoft was able to confirm that the LCS Services would not start with the information in the System Container as well as the Configuration Container. After using the migration script to delete the System Container information the service still failed to start. I ran a domain prep check on the domain and was able to see the Microsoft container was not showing as ready. Once the domain prep was run again, all permissions were correctly added to the objects in the Configuration Container and the LCS Services would start and everything was functioning again.
To summarize key things to note about the process that differs from the documentation:
- You must delete the information from the system container before running domain prep or else Domain Prep will not be able to add the permission correctly and the LCS Services will not start.
- When updating the user DN References it may not always show as completed, however you can verify by checking the msRTCSIP-PrimaryHomeServer setting through ADSI Edit.
Hopefully Microsoft can get this documentation updated soon, or atleast an announcement about this in a public blog, I have to imagine this is causing a lot of havoc on the LCS to OCS Migrations.