Wednesday, March 28, 2007 5:17 PM
I am attempting to install OCS 2007. I am running the SE setup.exe on my Schema Master. It fails to complete and comes up with the errors below.
Office Communications Server 2007 Deployment Log
Time Logged: Wednesday, March 28, 2007 10:11:22 AM
Execute Action Failure [0x80072035] The server is unwilling to process the request.
Initialize Forest Object FQDN: xxxx.com Local Forest: True Success
Initialize Active Directory Connections Domain: xxx.com
Windows 2000 Native Mode Domain: True
Global Container DN: CN=System,DC=xxx,DC=com
Global Container Domain DC: dc1.xxx.com
Domain DC: dc1.xxx.com
Forest GC: dc1.xxx.com
Schema Prep Schema Admin: True
[0x80072035] The server is unwilling to process the request.
Check Schema Prep State Schema Prep State: Live Communications Server 2005 with SP1
Upload Schema LDF Path: C:\temp\setup\i386\\schema.ldf
[0x80072035] The server is unwilling to process the request.
The server is running Windows 2003 SP2 (is that my problem?). I have previously been running LCS 2005 adn it is possible that the uninstall of LCS did not clean up my AD.
Any ideas would be appreciated.
Wednesday, March 28, 2007 5:55 PMAre you having any domain issues? It sounds like there is a GC access issue. If the domain is not stable, schema extensions cannot be completed. LCS 2005 to OCS 2007 works just fine - the schema prep extends additional objects; uninstalling LCS will never remove AD schema objects, so no worries there. Check AD replication and general AD health. If you are a single DC/GC, ensure there are no errors on the DC...
Wednesday, March 28, 2007 6:04 PM
Thanks for the quick reply. There are no domain issues that I am aware of. AD replication is fine, dcdiag and netdiag all run without problems.
The DC event log shows no issues either. I am running the setup on the Schema Master so the remote registry issue should not be a problem. I've also ensured that the registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Schema Update Allowed is set to 1 also.
Any othe ideas?
Wednesday, March 28, 2007 6:18 PMHave you tried running the schema prep from the GC directly? How about the simple reboot of the DCsvto ensure there are no DB locks?
Wednesday, March 28, 2007 7:21 PM
I was running the setup on the GC directly. I have rebooted both of my DCs.
Do you know if the OCS setup works on a SP2 system?
Wednesday, March 28, 2007 8:03 PM
Hmm - odd. Well two things:
1) Try running setup from the OCS server and let it remotely upgade the schema; this is the default behavior and should work just fine assuming your are loged in as a schema admin.
2) I am not sure sp2 testing has been completed. In general beta on beta can cause problems, although I would be a little amazed. There is nothing special from the domain level that is happening; you are simply making calls to extend the schema. Are your DCs running sp2? I can definately setup a test server and try this if you are still having problems to eliminate the sp2 as the issue.
Wednesday, March 28, 2007 8:10 PM
I've moved forward a little more on this. I decided to run the Schema Update manually running ldifde -i -v -k -s DC1 -f schema.ldf -c DC=X "DC=xxx,DC=com"
This generated the following error
Add error on line 2307: Unwilling To Perform
The server side error is "Schema update failed: An attribute with the same link identifier already exists."
Looking in the schema.ldf file the entry shows..
description: This attribute points to the MCU factory that this MCU belongs to.
I guess my next step is to try and find the duplicate LinkID although I'm not sure I know how to do that yet. More research...!
Wednesday, March 28, 2007 8:22 PMWas a previous update started and then failed possibly causing some of the attributes to be created/registered? Does your schema have any additional extensions in it from other apps (custom or otherwise)? I find it odd that even with the /k option it stops. Are the DCs running sp2 or just the OCS box?
Wednesday, March 28, 2007 8:26 PMAdditioinally, the following link talks about Link IDs and lists two available IDs which are reserved by the Exchange team so you can safely use them (assuming Exchange is installed and/or will not have any conflicts if it were to be installed). http://support.microsoft.com/default.aspx/kb/917682
Wednesday, March 28, 2007 9:22 PM
I'd already read the Exchange posting. I don't see how arbitrarily using a free LinkID will solve anything. I assume that OCS will need that LinkID sooner or later?
I'm trying to find out what other object in my AD uses that LinkID unfortauntely so far I haven't been able to work that one out. If you look in ADSIEdit on your system do you see the 7 MCU entries below?
Wednesday, March 28, 2007 9:46 PMReading the article I was not under that impression (from the Exchange side) - but I do see your logic trail. When running the ldifde a result log shoult have been created - opening that with notepad should point to the specific failure for the import. I do have all of the schema objects listed in your list - however; you have CN=ms-RTC-SIP-EnterpriseMCUSettings,CN=Schema,CN=Configuration,DC=X,DC=com listed 4 times in your list (and I only have it once as expected). All of the other objects were introduced with OCS 2007 so if you did not have a previous beta version installed, they were imported during this installation.
Wednesday, March 28, 2007 9:52 PM
I think I'm almost there. I've managed to find the duplicate LinkID (it's from a key token system made by Aladdin Systems. Fortunately we only installed this for a trial so I can remove it without any issues.
Now all I have to do is make AD let me edit/delete the specific Schema entries I don't need/want.
I think I can run with it from here, but I really do appreciate your assistance.
Wednesday, March 28, 2007 10:06 PM
Sure enough - that did it.
After only 8 wasted hours, I'm heading the right direction again.
Thursday, May 17, 2007 10:11 PM
I am having the same problem. The Schema update fails at the point where it
is supposed to add the MCU sections.
How did you find the duplicate LinkIds?
What did you do to fix it?
Friday, May 18, 2007 3:45 AM
I used Softerra's LDAP Administrator to query AD and return me all entries where LinkID was not blank. From there it as quite easy to find which product caused the duplicates, which in my case was Aladdin's eToken. We had only installed that as a trial and so I knew I was quite safe in deleting those particular entries.
The following information will allow you to remove the LinkIDs (and almost anything else in AD) but I DO NOT RECOMMEND YOU DO THIS UNLESS YOU KNOW EXACTLY WHAT YOU ARE DOING. THIS PROCESS CAN TOTALLY TRASH YOUR ACTIVE DIRECTORY REQUIRING A FULL RESTORE.
YOU HAVE BEEN WARNED!!!
Here's the link - good luck!
Tuesday, May 22, 2007 4:42 PM
Thanks for the info, it helped me figure out what was going on.
It seems that Microsoft has hardcoded the LinkIds in the Schema.LDF file
these show up starting in the MCU section of the Schema file. They want to
use LinkIDs 11026 thru 11037.
Our problem is that these are already in use by another application, we wrote
a line of business financial application sometime ago that required multivalue
attributes that were added an linked to the user class.
Using guidance from Premiere support we devised an app to determine the next
available LinkID and then created the attributes using the next free LinkID.
This seemed to be the best practice at the time.
However we now have a collision between these LinkIDs.
My question is can we simply increment the LinkIDs in the Schema LDF file and keep
moving or will this put us in an unsupported configuration? Will this break future updates?
any ideas? .... anyone?