Replacing a PDC
Results 1 to 7 of 7

Thread: Replacing a PDC

  1. #1
    Registered User
    Join Date
    Nov 2000
    Location
    Fountain Valley, CA
    Posts
    507

    Post Replacing a PDC

    I need some help:

    I am going to be replacing an NT server with a brand new NT server computer. What is the best way to go about doing this?

    thanks,
    tim

  2. #2
    Registered User storm's Avatar
    Join Date
    Apr 1999
    Location
    fredericksburg, va, usa
    Posts
    322

    Post

    before you take it off line make sure you copy all the config info, if your running wins or dhcp server get screen shots of the wins config and if your running dhcp make sure you have the scope info.

    do you have a bdc? if you do promote the bdc to a pdc, then rebuild the pdc.

    some other stuff..if you use logon scripts take note of where they are on the pdc so you can copy them back from the bdc.

    some of the obvious stuff, make sure you have drivers for all your devices and the latest service pack

    take you time and it should go pretty smooth, run into a snag post on back..

    later, storm
    "no eternal reward will forgive us now for wasting the dawn"

  3. #3
    Registered User
    Join Date
    Aug 2000
    Location
    Largo, Fl USA
    Posts
    197

    Arrow

    From http://www.techrepublic.com Great Advise...Conventional IT wisdom says you should approach complex network changes with caution, rolling them out in stages so that your business can keep running if you hit any snags. But if you're planning to roll out Windows 2000, where do you begin? That's the focus of this week's Microsoft Challenge, which was supplied by a TechRepublic member who's about to deploy Windows 2000 throughout his organization.

    "We have gone through the servers in question with the Compatibility Analyzer," he wrote, "and have identified various drivers and applications that need updating. But now what?" With primary and backup domain controllers, Exchange Server, and IIS4 to deal with, what's the most sensible strategy? Three TechRepublic members offered excellent battle plans, all based on hands-on experience with this tricky upgrade.

    For starters, said TechRepublic member Magetower, make sure your existing network is running without any glitches or hiccups. "Your servers and services should be running at least the required level of service pack/driver required to do the upgrade. If you need to apply a service pack, let it run for a while to make sure it doesn't create problems before upgrading."

    Next, you should map out exactly which Windows 2000 features you want to add to your network. This is especially important if you plan to implement Active Directory. In that case, said Magetower, "you would need to do the PDC first, as this will directly affect the upgrades of the other servers, particularly the Exchange Server."

    Instead of experimenting with your live network (with possibly disastrous consequences), why not build a small test lab using a spare PC or two? A TechRepublic member with the colorful handle Last Survivor recommended handling the job this way: "Take a spare machine and build it as a BDC in the active domain. Take it off the network. While still offline, upgrade the server to a PDC. Install Windows 2000 Server and see how well all your account information comes over. Play with the admin tools on this server to get a handle on how you want to design your new AD domain."

    Having a rock-solid network backup is essential, of course, but TechRepublic member sevans suggested going one step further by building in a fail-safe mechanism. "Before proceeding, you must provide a fallback to NT4. Create a new BDC, synch it with the existing domain, and take it offline. Now you can upgrade the PDC to Windows 2000, but keep in mind that this should be done offline until the AD installation portion of the upgrade is ready to begin. Once the upgrade is complete and all seems to be functioning well, start upgrading other DCs and the Exchange Server. Don't leave your RAS servers until last. Above all, check and double-check DNS. Any DNS issues will prevent the AD from functioning correctly. Finally, make sure that all of your DCs are time-synched together, or the security policies and domain synchronizations will begin to fail."
    Last Survivor offered a slightly different plan to keep your Windows 2000 network from getting voted off the island:

    Build a BDC in your NT4.0 domain. Let it synch up, and then take it offline and put it in a safe place. This is your rollback insurance. If anything goes wrong, you can bring this closeted BDC back online, make it your temporary PDC, and get back to a functioning NT4 domain.
    Pick out one of your existing domain controllers, preferably the most powerful one, in the best location. Make this server your PDC and upgrade it first.
    Upgrade your Exchange Server, to extend the AD Schema.
    Upgrade your BDC. You can then safely turn on Native mode for Active Directory, which gives you all the 2000 features.
    Assuming those server upgrades go well, you can proceed to upgrade workstations, adding them one at a time to the new Windows 2000 AD.

    Every expert who looked at this problem counseled caution when upgrading the IIS server, because it's running proprietary applications. Magetower recommended cloning the server before attempting the upgrade; that safeguard lets you pull the new server offline and replace it with the old version in case of trouble.

    Take it slow, have great backups, and start with the PDC. Anything else to watch out for? After doing this migration three times, sevans offered one final word of advice: "Cross your fingers and pray."
    Good Luck to You Be sure to run a full backup first.
    Frank Duffey Tampa Bay communications Inc.
    Computer Shop Owner A+ COMPTIA
    Tampa Bay Communications Inc
    http://www.smokinparts.com/smokinpartslogo

  4. #4
    Registered User
    Join Date
    Sep 2000
    Posts
    1,965

    Post

    To go off topic for a minute:
    One thing I learned about logon scripts, the hard way, is that we copy them to our BDC every night! We were having a problem where they would only run about half the time. We traced the problem to the fact that the scripts were on #1 and the people were authenticating on #2. Just a little hint from experience.

    Back on topic, the advice that Frank (Vice Pres) posted, is very good, as is all the advice posted so far. I would take this in to consideration when replacing a PDC.

    Originally posted by storm:
    some other stuff..if you use logon scripts take note of where they are on the pdc so you can copy them back from the bdc.

  5. #5
    Registered User
    Join Date
    Nov 2000
    Location
    Fountain Valley, CA
    Posts
    507

    Post

    Thanks for all the advice. I just wanted to clear a couple things up:

    (by the way, I am replacing a PDC on a network with a brand new machine. There is no BDC on the network.)

    Am I to understand that I should just do a fresh install of NT server, and specify BDC during the setup? If I do this, I need to be on the network, connected to the existing PDC, right?

    My tech already installed NT server as a PDC at our shop. Will I need to re-install NT server at the client's office, connected to their PDC?

    Hope this makes sense, thanks again.

    tim

  6. #6
    Registered User storm's Avatar
    Join Date
    Apr 1999
    Location
    fredericksburg, va, usa
    Posts
    322

    Post

    if all you have is a pdc and not a bdc then all your sid's and the sam database is going to be wiped out which means you would have to recreate all the machine and user accounts.

    in /winnt/system32 there's a folder called /config copy it out then after the rebuild copy it back.
    "no eternal reward will forgive us now for wasting the dawn"

  7. #7
    Registered User
    Join Date
    Nov 2000
    Location
    Fountain Valley, CA
    Posts
    507

    Post

    ok, i pretty much got it. thanks for all your help. It was actually pretty easy, I was just a little nervous because I have never replaced a pdc before.

    I did have one minor problem though. When I log on with one of the client machines, I can see my logon script run, which should map drive Q: to \\server\quickbooks. However, drive Q: does not get mapped. This is really weird! If I manually run the script (logon.bat), the drive gets mapped. But not automatically when I log on.

    Has anyone seen this before? It's really weird...
    tk

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •