No announcement yet.

Best practise for deployment to site

  • Filter
  • Time
  • Show
Clear All
new posts

  • Best practise for deployment to site


    I have been asked to provide reasons as to why I would deploy a new 2008 R2 x64 server to a branch office in the following way:

    • Install the OS, patch and join to existing Forest
    • Install necessary printers
    • Prepare required software for Terminal Server applications
    • DCpromo add necessary services
    • Create necessary shares as well as share out printers

    Existing Server:
    • The existing AD/DC will stay on line during this deployment
    • Always uses a specific IP and provides Terminal Services, file and print services as well as the DNS/DHCP.
    • There are printers that use the DNS from the existing server and a particular wireless device which uses the DHCP as a DHCP relay for scan guns so items can be added to and removed from inventory.

    At conclusion:

    So here are the actual deployment challenges and my comments or questions are in bold:

    1. I was taught to give a new AD/ DC a different IP than the AD/DC it would replace.
      • Correct, incorrect or not really a big deal?

    2. The issue at hand is that the devices relying on the existing server have to be manually updated. The argument here is that they wouldn't need to be updated if I just changed the server IP to match the one being retired.
      • Am I just being difficult here or should I change the IP once the old server is offline?

    3. Of course these replacements occur during working hours.
      • I know this makes it difficult for the cut-over no matter which I way I proceed...

    4. If we use a new IP, we have touch those other devices.
      • Personally not a big deal to me...

    I have consulted with a colleague of mine and he happens to agree with me. However he also will assign all printers and devices permanent leases along with DHCP reservations. He reasons that if you ever have to replace the server, the DHCP database can be imported easily enough. My colleague also believes that would satisfy both the different IP method as well as the existing admin's

    The existing admin is questioning my methodology which has worked without issue and I used this method as it is what I know is safe.

    However... the first time I deployed a server using this method for my current employer there were a lot of gotchas. Many of the configurations for printers and devices were not documented by the previous admin and I had to figure it out as each problem came up. No big deal - it's all documented now.

    The second time I deployed a server the same questioning of my method came up. Because I now had the correct documentation, I was able to deploy things without any incident or set back.

    What I would like from you readers is: Which way would you have gone here? Any technical reasons as to why or why not to do it the other admin's way or even my own preferred way...

    Thanks very much in advance.


  • #2
    Re: Best practise for deployment to site

    I've done a cutover where we had to build and deploy a new server, then shutdown the old DC, and change the IP on the new one to be the same as the old

    A quick, fast, 1-2 operation done out of hours, followed by a mandatory reboot of every device.

    It can be done, and there's not huge concerns in doing git really, as long as you remember to physically disconnect the old server......

    Either way is effective, and relatively low in risk, except where you have things manually pointed to a specific address...
    (in our scenario, a large number of helpers over 15 or 20 routers would have needed to be updated, via a 3rd party, and this way was just deemed much easier, and more effective (and more trust in us than the 3rd party)
    Please do show your appreciation to those who assist you by leaving Rep Point


    • #3
      Re: Best practise for deployment to site

      Hey Tehcamel.

      Thanks for the reply - insightful and to the point. I really needed to get some perspective as it doesn't matter to me which way the company goes with it. I just feel a little better knowing someone else has done this the same way via changing IP's.

      Thanks again.


      • #4
        Re: Best practise for deployment to site

        no probs

        i think from memory, we built and deployed the new DC on it's own IP address.
        Then we did the same at the second site a nd moved FSMO roles
        We let it bed in for a week, checking regularly for repl errors, or any errors really.

        shutdown the original dc, took it's IP Address.
        Waited a week, repeated at second site
        then created an airgap, changed the ip addresses of the old DCs, powered them back up and put them on the network, then demoted them and ensured we cleaned up

        we then shutdown and removed the old servers, as they were almost 5 years.. :_
        Please do show your appreciation to those who assist you by leaving Rep Point