Hello, So like everyone else, I'm on the "if rebuilding site, change site code, change server name" bandwagon. However, I'm in a unique position where that is not possible. Large environment, very controlled and yet hard to predict what other processes/reporting they've got that ties into the site coding. We restored from a backup but it may have been compromised, is fairly old and we keep finding components that aren't working right. Spent many hours troubleshooting those failed components and at the point now where there aren't many errors, but packages won't trickle down, CI insertion errors, etc... We want to turn the server into a smoking hole and get back on track. Got a few deployments that need to go soonest and time is limited. I'm planning on doing the following here - Disjoin site server from hierarchy. Wait a while as this trickles through. Uninstall site serverVerify that all objects have been removed from the Systems Management container. (no WINS component here to worry about)Rebuild server from scratch. Join to domain, readd to all the proper security groupsOnce site server is back up and running, verify the MP/boundaries have been pushed to SysMan container. Discover clients. Run ccmsetup.exe RESETKEYINFORMAITON=TRUE on the clients. Again, I realize that changing site code/server name is best practice here, but I can't do that. Far as I know, the AD objects and client Key are the main reasons for NOT reusing a site code. Is there anything that I'm missing? Thank you in advance for any responses and recommendations.

Not only is it best practice not doign so WILL CAUSE failures. Clients keep a record of every package and advertisement. If you build a brand new site using the same site code those previously used records will remain on the clients. Let's say you deployed Office 2007 and that ID was CEN0001. On the new server you deploy Adobe and guess what, it's ID is also CEN0001. You clients WILL NOT run the new package because they think they've ran it before. You can get away with reusing secondary site codes but it is 100% impossible to reuse a primary or central site code PERIOD. Nothing should even be "tied" to a site code. They should be random and meaningless. I'm sorry you feel like you can't change it but that's your ONLY choice if you can't restore a backup.John Marcum | http://myitforum.com/cs2/blogs/jmarcum/|

So that's the most compelling argument I've heard thus far for changing site codes. I thought of that a few days ago, but we somewhat mitigate that by hosting all adverts and packages (ergo, all package and advert IDs) from a higher tier. Nothing is done from the child primary (which begs the question - why not a secondary site...but not my question to answer unfortunately). Again, I agree. Unfortunately, its a decision way above my head.

Trust me, whomever is making this decision will regret it. :-( There's no reason to not change a site code. What could possibly be tied to a site code? I totally agree with you about the secondary site. If all administration is done at the parent site why even have a child primary site. John Marcum | http://myitforum.com/cs2/blogs/jmarcum/|