preping the schema for OCS2007 RRS feed

  • Question


    I have a slight problem.  I ran the schema prep from the OCS2007 setup.exe from my future ocs server which is not a domain controller.  The prep said that it was successful and the logs say it was all successful... but when I verify with ldp.exe I can't find any of the changes..  I ran the same thing in my test domain environment and I was able to see all of the new entries and verified the schema version using the following directions..


    To manually verify that the Prep Schema was successful and that schema changes were replicated to child domains

    1.       Log on to the parent domain controller as a user with Enterprise Admins credentials.

    2.       Click Start, click Run, click Browse, locate Ldp.exe and select it, click Open, and then click OK.


    The file, Ldp.exe, is one of the several additional command-line tools that can be used to configure, manage, and debug Active Directory. These tools are collectively known as the Support Tools and are available on the Windows 2000 Server or Windows Server 2003 operating system CD in the \SUPPORT\TOOLS folder. Extract the file from the Support.cab file.



    3.       On the Connection menu, click Connect, and then click OK.

    4.       On the Connection menu, click Bind, and then click OK. This will use the default Enterprise Admins credentials.

    5.       On the View menu, click Tree, and then click OK.

    6.       In the console tree, click DC=domain name, double-click CN=Configuration, DC=domain name, double-click CN=Schema, CN=Configuration, DC=domain name.

    7.       Under the schema container, search for CN=ms-RTC-SIP-SchemaVersion. If this object exists, and the value of the rangeUpper attribute is 1007, then the schema was successfully propagated. If this object does not exist or the value of the rangeUpper attribute is not equal to 1007, then the schema was not modified.




    I don't really want to re-run the schema prep..  as I'm afraid it could mess something up.  The only difference between my production domain and my test domain is I did the prep on my test domain on my actual schema master DC, as opposed to doing it remotely from my production domain.  I assume that had to have something to do with it but I'm just concerned about the fact that OCS responded back with all successes?


    Is there any danger in re-doing the schema prep from my schema master DC to ensure it's successful?  Or should I just continue on with the forest and domain prep even though I can't find the changes in ldp?



    Monday, June 16, 2008 5:49 PM

All replies

  • You should be able to proceed without any issues if the setup program is allowing you to do so.  If there is a replication delay or other problem then you will not be able to complete the next step.

    Monday, June 16, 2008 6:32 PM

    Run the following command.


    LCSCmd.exe /Forest /Action:CheckSchemaPrepState

    Monday, June 16, 2008 7:43 PM

    I have a suspicion I messed something up...  and probably because im trying to do everything on a single server for a POC.


    I've deployed OCS2007 enterprise on a single server, and none of the services are completing validation.  I think they are complaining about the ssl certs that I have created and deployed into IIS.  My suspicion is it's not deployed correctly in IIS, but I don't know enough about IIS to know where I made my mistake.  I also made the mistake of trying to enable every function on this one box(I enabled IM archiving as well which probably should not be here..).


    I'd kind of like to scrap the whole thing, uninstall everything and start over...  since my AD domain is prepped that should at least stay..


    Is there any issue with doing so?  I seem to have way too many errors to fix within my validation.  Will my ssl cert stay valid if I keep my hostname and pool name the same?

    Tuesday, June 17, 2008 8:58 PM

    I'm with you on starting over since you're not concerned about service outage.  In a single server POC I would recommend using a Standard Edition server and when you are ready to roll out full production, build your enterprise pool then and move the users over.

    To avoid validation issues on your next try, take a look at Jeff Schertz's blog on renaming an OCS server to guide you through cleaning out OCS stuff from your AD before you give it another go.



    Wednesday, June 18, 2008 2:01 AM
  • Thanks for the link to the blog.. I'll have a look at that. 


    Will there still be an issue with renaming an OCS server/cleaning out the AD stuff if I plan on using the same actual server/hostname?  My plan was to just uninstall all the office comm stuff,  keep sql server 2005 around, and just re-install the standard edition.  My hope would be that all of the AD prep stuff would still be relevant since I'm not changing hostname/IP addresses and anything that was related to enterprise only features would just become useless until I actually built out a new enterprise server(in which case I would need to clean them up.)




    Wednesday, June 18, 2008 2:05 AM

    I'd get rid of the SQL server since it's not required for standard and all of the pool info from AD.  You may want to check your AD health too be sure everything is replicated before you go to reinstall (dcdiag /e).



    Wednesday, June 18, 2008 2:18 AM

    ahh..  originally I was going to deploy standard.. so I had installed sql server 2005 express, and when I did enterprise it told me it was invalid, so I had to upgrade to the full blown sql.. I suspect that was probably why I had express installed in the first place.



    within AD, are there specific places I should look?  I noticed that the installation created a bunch of universal groups, and I also noticed that under users and computers\system I have a microsoft folder which has a RTC service folder...  Within here seems to be alot of office comm/sip stuff.  Are there other places?  Do I just need to delete this RTC service folder from users and computers and let that replicate out?  I assume the universal groups wont hurt anything if they are left behind.



    Wednesday, June 18, 2008 2:24 AM
  • If you want to rip the entire ocs sstem from ad, delete the rtc sevices folder.  If you don't have lcs in your environment, install ocs into the configuration container.  It may save you some headaches as the network grows.


    Wednesday, June 18, 2008 2:38 AM

    the mention of the configuration container is interesting... I had read about it in some of the documention I had read(although I don't remember which doc it was..)  the problem I seem to have is..  I can't find a configuration container anywhere within AD Users and computers..  the closest thing is the DFS-Configuration container.. which I wouldn't suspect is right, but I don't have a single separate configuration container.



    Wednesday, June 18, 2008 2:52 AM
  • When I went to delete the RTC Service folder within the microsoft folder(under the system container), I got a message asking if I wanted to mark the exchange mailboxes for deletion as well.  I don't recall setting up any accounts that had exchange mailboxes so that question was a bit odd to me.  I am pretty sure there shouldn't be any ill effect from doing this because the top level folder was created yesterday.. so there shouldn't be anything that depends on it..  but sometimes I just get the willies..   what could this mailbox belong to?


    also, when I delete the rtc service folder.. will I have to re-run a domain/forest/schema prep?

    Wednesday, June 18, 2008 3:06 AM

    The prompt you are getting is from ADUC isn't it?  That question dialog is a function of the ADUC GUI with Exchange 2003 if I'm not mistaken.  You will want to use adsiedit.msc for you cleanup efforts.  You can allow setup to detect readiness - forest prep is the one that creates the config container objects so at least that will have to run and likely domain prep again too becuase there are permissions set to the groups it creates within the config container.  Schema prep will not need to be run again.

    Wednesday, June 18, 2008 5:28 AM