Windows 2003 STD and replacing an entire domain...

[qzmicro]

Hi there. My domain is a mess, I'd like to build a new server, build a new domain (same name as my original) and rebuild all services on my network on the new domain controller. Now then, my question is... for my clients, do I just unjoin them to the old domain, and then rejoin the to the new one (with the same name as the original)? Is there anything that anyone can suggest or foresea as a problem? My goal is to start from scratch. This Domain has been upgrade, downgrade and bogged down to s***. Buggy all over the place and now is starting to give me GUI problems. At the end of the day, I would like to start from scratch, but need to knwo if my clients are going to see any problems working with the new domain controller and new SIDs and new all that. Please let me know if I am not being clear. I wnat to know if there is anything complicated about this, or if it is pretty straight forwrads. Thanks for your time, much obliged.

Tony

P.s. I do plan to use the same HOSTNAME and DOMAIN NAME for my new domain controller.

Edited September 9, 2007 by qzmicro

[InTheWayBoy]

Well if you plan on replacing the current domain, even with the same name, I would think you're gonna run into some issues. Nothing you can't fix but it won't be just a simple process. User's profiles and data will have NTFS permission conflicts. If you're running exchange you'll have to deal with that as well since it hosts a major part of itself in active directory. GPO software installations might bug out.

If I was doing what you it, I would angle to have all the users create new profiles and use something like xcalcs to edit their personal data to work on the new domain. Get the new domain running in a way that it can't communicate with your current domain, don't want things like DHCP mixing things up for now reason yet. Export as much info as you want from the current domain, at the least usernames and groups so you won't have to manually create them. You can use various tools to get that stuff to ldif files, which is the best for this operation. You should import this first, especially if you export security groups and you want to configure GPO's based off them.

Install the same services on the new domain, then configure as necessary. You should let DNS start fresh, nothing from the current domain...same for DHCP and WINS, joining the clients to the new domain should get that all working. I don't know for sure about this one, but I would think you could configure the same GPO software installs. I'm thinking when it logs on to the new domain it will initiate a reinstall of the application. If they are getting new profiles this shouldn't be a big deal unless the software is something special. If you don't do this you might leave orphaned installs on the clients that could be problematic to uninstall/update. Again, I'm not 100% on that.

If you run Exchange I would imagine you can export the mailboxes and public folders, along with other config parameters (ldif again). I've never had to do that yet, would kinda give me a reason to re-evaluate the idea.

For the clients, I would login as local admin and break it from the current domain to a temporary workgroup. Then remove any profiles, you may want to back them up depending on what they contain. If you do folder redirection you shouldn't have to worry about much. A few tweaks, like ipconfig /flushdns and getting a new DHCP lease from the new domains DHCP server...possibly reseting the local group policy to the factory defaults (That way your new GPO's have a standard config to work with), and then join it to the new domain.

You should be able to preprep most of it, and then in one night do the switch over. Of course depends on the number of clients. Almost all of this could be automated if you good at scripting. Your clients will need to be reconfigured, but depending on how in depth your login scripts are it may only be minor things. For my setup each new profile is setup using a combonation of a custom default user profiles and login scripts. But there is always some pains, like printers and such. Oh yeah, you'll have that to worry about too, especially if the printers are hooked up to the clients and shared through AD.

Hopefully someone else has some better ideas for ya, mine is a little too manual even for my own taste.

[qzmicro]

Well if you plan on replacing the current domain, even with the same name, I would think you're gonna run into some issues. Nothing you can't fix but it won't be just a simple process. User's profiles and data will have NTFS permission conflicts. If you're running exchange you'll have to deal with that as well since it hosts a major part of itself in active directory. GPO software installations might bug out.

If I was doing what you it, I would angle to have all the users create new profiles and use something like xcalcs to edit their personal data to work on the new domain. Get the new domain running in a way that it can't communicate with your current domain, don't want things like DHCP mixing things up for now reason yet. Export as much info as you want from the current domain, at the least usernames and groups so you won't have to manually create them. You can use various tools to get that stuff to ldif files, which is the best for this operation. You should import this first, especially if you export security groups and you want to configure GPO's based off them.

Install the same services on the new domain, then configure as necessary. You should let DNS start fresh, nothing from the current domain...same for DHCP and WINS, joining the clients to the new domain should get that all working. I don't know for sure about this one, but I would think you could configure the same GPO software installs. I'm thinking when it logs on to the new domain it will initiate a reinstall of the application. If they are getting new profiles this shouldn't be a big deal unless the software is something special. If you don't do this you might leave orphaned installs on the clients that could be problematic to uninstall/update. Again, I'm not 100% on that.

If you run Exchange I would imagine you can export the mailboxes and public folders, along with other config parameters (ldif again). I've never had to do that yet, would kinda give me a reason to re-evaluate the idea.

For the clients, I would login as local admin and break it from the current domain to a temporary workgroup. Then remove any profiles, you may want to back them up depending on what they contain. If you do folder redirection you shouldn't have to worry about much. A few tweaks, like ipconfig /flushdns and getting a new DHCP lease from the new domains DHCP server...possibly reseting the local group policy to the factory defaults (That way your new GPO's have a standard config to work with), and then join it to the new domain.

You should be able to preprep most of it, and then in one night do the switch over. Of course depends on the number of clients. Almost all of this could be automated if you good at scripting. Your clients will need to be reconfigured, but depending on how in depth your login scripts are it may only be minor things. For my setup each new profile is setup using a combonation of a custom default user profiles and login scripts. But there is always some pains, like printers and such. Oh yeah, you'll have that to worry about too, especially if the printers are hooked up to the clients and shared through AD.

Hopefully someone else has some better ideas for ya, mine is a little too manual even for my own taste.

Thanks so much for your response. It was more or less what I had in mind. I figured there will be many small problems, but I am looking ot avoid big issues. There is no GPOs or Profiles to the best of my knowledge on this network, so I think it will be faily easy. No Software lists either... most users administer their own machine. I am looking to change this. I just started here 3 weeks ago, I'm not sure what the hell the last admin was thinking.

Tony

[eyeball]

could you not add a seconds domain controller and slowly migrate things over like the fsmo roles ect, you could manually tidy up AD, DNS and DHCP and the users would probably have no clue you were making any changes at all. Get yourself a test XP pc and begin adding GPO's and locking machines down and at least test it on there first then roll it out.

Surely all these bugs you are referring to are down to the configuration of the computers and not the domain. a reinstallation of your current server would solve your problems and this could be done once your new domain controller is controlling everyhting.

P.S - how many servers do you have?

Edited September 9, 2007 by eyeball

[cluberti]

This is true - perhaps if we knew what the problems you are seeing were, and the extent of these, we could help you clean it up. Moving from one domain to another isn't necessarily the wisest thing to do (although your move would likely not be difficult due to such a simple domain), nor is it necessary.

[qzmicro]

This is true - perhaps if we knew what the problems you are seeing were, and the extent of these, we could help you clean it up. Moving from one domain to another isn't necessarily the wisest thing to do (although your move would likely not be difficult due to such a simple domain), nor is it necessary.

...

could you not add a seconds domain controller and slowly migrate things over like the fsmo roles ect, you could manually tidy up AD, DNS and DHCP and the users would probably have no clue you were making any changes at all. Get yourself a test XP pc and begin adding GPO's and locking machines down and at least test it on there first then roll it out.

Surely all these bugs you are referring to are down to the configuration of the computers and not the domain. a reinstallation of your current server would solve your problems and this could be done once your new domain controller is controlling everyhting.

P.S - how many servers do you have?

...

Thanks guys, you are very kind. Here is my problem. I naturally tried to migrate, but had issues joining another DC to the domain. I could not use a 2000 DC because the hardware I got is not compatable with 2000, only 2003. I worked with the vendor on this one. So, I need to forest prep and domain prep. However, I cannot prep because of an LDAP error. Hence, I could not dcpromo it. It gave me the error on the attached jpg file. Please ignor the last line as i was trying to view it with the edit command and jsut typed in the filename.

Tony

P.s. I have a network with one domain controller (AD/DNS/DHCP/Print/File) and a member server (PBX/Phone System). There are about 25 clients, mostly XP... mixed 2000/XP/Vista.

Edited September 10, 2007 by qzmicro

[qzmicro]

Bump.

-Q

[cluberti]

Even though you only have one DC, did you at any point on this network have 2 or more? This error is most commonly seen when FSMO roles are not successfully transferred from one DC to another, and then the role owner was demoted and FSMO roles are then out of whack (and your domain WILL suffer GREATLY). Using ntdsutil to sieze all the FSMO roles (even if it says they're already held by the only DC left on the network) is a good start.

Another reason I have seen in my travels is that the IP Security section of the domain in LDAP is missing, which you can check in adsiedit under Domain > System > IP Security (if it's not there, that's bad - your Domain partition will likely be screwed up ). If this is the case, and if you've got another server on the network without major problems you can try importing the HKLM\Software\Policies\Microsoft\Windows\IPSec key into the DC, and/or you can try exporting and importing the IPSec object:

- export:

ldifde -d "CN=IP Security,CN=System,DC=<domain name>,DC=com" -m -f c:\ipsec.ldf

- import:

ldifde -i -f ipsec.ldf

However, if this really is the only DC, and seizing the FSMO roles don't help, you really will have to rebuild (and you can forget about setting up trusts and moving anything, because the Domain partition is lost and security has failed). Sorry to say it, but you may really indeed be needing a rebuild.

[qzmicro]

Even though you only have one DC, did you at any point on this network have 2 or more? This error is most commonly seen when FSMO roles are not successfully transferred from one DC to another, and then the role owner was demoted and FSMO roles are then out of whack (and your domain WILL suffer GREATLY). Using ntdsutil to sieze all the FSMO roles (even if it says they're already held by the only DC left on the network) is a good start.

Another reason I have seen in my travels is that the IP Security section of the domain in LDAP is missing, which you can check in adsiedit under Domain > System > IP Security (if it's not there, that's bad - your Domain partition will likely be screwed up ). If this is the case, and if you've got another server on the network without major problems you can try importing the HKLM\Software\Policies\Microsoft\Windows\IPSec key into the DC, and/or you can try exporting and importing the IPSec object:

- export:

ldifde -d "CN=IP Security,CN=System,DC=<domain name>,DC=com" -m -f c:\ipsec.ldf

- import:

ldifde -i -f ipsec.ldf

However, if this really is the only DC, and seizing the FSMO roles don't help, you really will have to rebuild (and you can forget about setting up trusts and moving anything, because the Domain partition is lost and security has failed). Sorry to say it, but you may really indeed be needing a rebuild.

Thanks so much for your input. I have been troubleshooting the problem and found that you seem to be correct. Master Roles were not transfered properly and this has lead to the AD issues I am having. At this oint, there were 2 DCs on the network that were simply taken down and never brought back up. Not sure what happend to the hardware or the OS. At this point, I will try and use ntdsutils to take ownership of these roles... if that does not work... I will have to rebuild. You have been very helpful.

Qz