Hi I did some migration test in my local lab. We plan to do a site by side upgrade, let packages and collections flow down the hierachy to the new server. After a successful replication the "downstream" server will become the new central. I broke the parent-child relationship, made the new server the central server in the hierachy. All servers are sorted in the hierachy as expected. The only issue is that packages and collection on "new" the central server are locked down. All packaged on the "old" central server are not locked. My expection was that a central takes care for package and collections locks. Is there anything I have to take care before making the new server the new central. I would appreciate any help. Regards Joachim

Hi Joachim, Normally the central site would also take care of the collections, packages etc. I have seen a similar issue like yours before. It can happen if you break the parent/cild relationship to quickly also when you recreate the parent/child relationship to quickly. I normally let the replication stay overnight.Kent Agerlund | http://scug.dk/members/Agerlund/default.aspx | The Danish community for System Center products

Hi Kent, thanks for the fast reply. That could be the reason because I am always very impatient. :-) One more question. What would you recommend to do first? Delete the sender addresses and then configure the new hierachy or leave the sender address in place and reconfigure the hierachy? I am unsure but first deleting the senders does make sense to prevent any further server to server communication which maybe can have an influence. Regards

Hi Kent, thanks for the fast reply. That could be the reason because I am always very impatient. :-) One more question. What would you recommend to do first? Delete the sender addresses and then configure the new hierachy or leave the sender address in place and reconfigure the hierachy? I am unsure but first deleting the senders does make sense to prevent any further server to server communication which maybe can have an influence. What is the correct sequence? X) delete old sender address X) create new sender address X) promote the child to a central server X) demote the central as child site x) reconfigure other primaries to report to the new central server Regards

Hi, you don't need to delete and recreate the adresses. I always leave the adresses in place, otherwise I might end up with data that cannot be replicated.Kent Agerlund | http://scug.dk/members/Agerlund/default.aspx | The Danish community for System Center products

Mmmh that exactly what I did yesterday. I leave the addresses unchanged, configured the new server as a new central. This morning collections still locked. Will try it again and maybe it works tomorrow. It would be a nice Easter present. :-) Keep you in loop... Regards

Ok I gave it another run and waited until next day. Collections are NOT locked anymore, so to be patiend is the key for success. Summary: 1) NO sender addresses have to be deleted 2) Promote the new server as a central server 3) Wait at least one day before hierachy reorganisation 4) Configure the subordinates to report to the new central server 5) Configure the old central server to report to the new central server and again be patient... Thanks Kent Regards Joachim

Hi Joachin, I seem to have a scenario just like yours. But in my case the set parent site on the new server is greyed out? Any clues has to why this is happening? PS: the replication is fine, i have the collections with locks on them, the packages also (yesterday the packages were without lock but this morning they were locked again why i dont know). Please help. Thanks.

Hi I am not sure if I got it right. You wrote the replication is fine on the new server so the parent site is set correctly. Can you give some more details please especially the hierachy you plan to set up. To set a new parent site sometimes the option is greyed out. In this case I make the server a central, apply the settings and after applying the settings I configure a new parent site. Let me know if this works Joachim

THANKS JOACHIM, here is my scenario server 1 parent site, sccm 2007 sp2 win 2003 x64bit, all site system roles except health validator and sup. server 2 current child pry child site, sccm 2007 sp2. win 2008 r2, does not include asset intelligence, sys health validator, site db (hosted on a remote sql server) the issue is on the pry child server the set parent tab is greyed out so i dont even get the option to set it back to a central site in order to break the relationship. thanks.

parent tab is greyed out so i dont even get the option to set it back to a central site in order to break the relationship. Any chance that it's a matter of ConfigMgr's security rights? Has your account "full control" on that site?

yes it does, it was the account i used to install the primary site server so automatically it was listed in the security user role

Any joys...still greyed out ... :(

Hi mmmh no more ideas from my side because it is not exactly my scenario I was faced with. I broke a lot of relations during my migration to reorganize the hierachy. Sorry, let me know if you find a solution. Regards

Thanks Joachim, I found a work around, i had to do a manual deletion of the site from the central site, uninstall the site server, re-install it and then re-attach...everything is fine now! Still cant figure out why it was greyed out. I realized its suppose to be greyed out when viewed from the central site but its supposed to be ok when viewed from the child primary site console itself. Thanks again.

Hi, I'm not sure if I should open a new thread but it's kind of related to this one so..... I have a question about step 5 of your summary. I am changing our Central site server to a new hardware. We plan to decommission our old server once everything work fine with the new one. I've read many articles / forums / web site about how to proceed and I'm currently doing a side-by-side migration. I just promoted my new server as a Central site and I know I need to wait at least 24 hours before proceeding to anything else... Here is my question: Many procedures I've read were suggesting to "configure the old central server to report to the new central server" (making the old server the child of the new server) but is it really necessary ? Is it a necessary step or is this step only good if I want to keep the old server as a primary child site ? Do you know if there is risk of not doing it ? Thanks for your help. Alain

Many procedures I've read were suggesting to "configure the old central server to report to the new central server" (making the old server the child of the new server) but is it really necessary That's only needed if you want to keep data (i.e. inventory, status messages etc) as it gets replicated up in the hierarchy. Torsten Meringer | http://www.mssccmfaq.de