Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

Mohammed Shah Newaj — Wed, 15 May 2013 10:36:50 GMT

Thanks

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

tonymorev — Mon, 01 Apr 2013 15:26:15 GMT

Greg, nothing yet as far as anyone contacting me.

I wonder if we are too small to be "worthy" of Premiere support.

I only have 15 Users with workstations and a render farm of about 50 machines.

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

Greg Jaworski [MSFT] — Thu, 28 Mar 2013 15:32:39 GMT

@tonymorev

1) Yes you can use the same IP when you replace the DC with another one. The one thing you should do is clean up DNS when you demote the old DC. This means cleaning up the NS records for the retired DCs as well as SRV and other records. To see the records the DC is registering you can look at the netlogon.dns file before you demote that DC.

2) It doesn't...You would assign a static address in the IPv6 world as well

3) My coworker John loses sleep at night when customers disable IPv6. I think he might be a zombie now. blogs.technet.com/.../why-you-should-leave-ipv6-alone.aspx Basically we do support disabling via the registry disabledcomponents key support.microsoft.com/.../929852, but we don't recommend it. If IPv6 is not in use and not configured on routers it does nothing. If it does literally break the app just because it is there then yes you can disable it following the above article.

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

tonymorev — Thu, 28 Mar 2013 14:42:31 GMT

Hi Greg! The deeper I dig the more questions keep coming up. This time it's IP related.

I'm going to break this down into 3 parts, but in a sense they very much connected.

1) The IPs on DCs will need to be static (even if just by DNS best practices). But in order to preserve some production continuity I will have to change the IPs on both of my new DCs after they go live to the values their predecessors used to occupy. What kind of underwater stones are waiting for me?

2) In the above I'm talking about IP4, how does IPv6 change any of that?

3) My clients are 99% win7 64-bit, IPv6 interferes with one of our mission critical applications and brings no benefits. Currently I'm disabling it on all my clients via GPO (I believe it's more that just a win config setting, but is actually a registry hack on top of that). Can I safely do the same to 2012 servers? Or is there a smarter way to avoid IPv6 all together in the domain?

I hope these are not too specific for just my case and someone else will find the answers useful.

Thank you so much!

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

Greg Jaworski [MSFT] — Wed, 27 Mar 2013 15:42:30 GMT

@tonymorev Yeah the H: drive won't be a problem for adding additional DCs. The C: drive argument is security through obscurity. It might stop the kid next door, but it would not stop the more experienced ones. Regardless not a problem. Other domain controllers don't care where system or database files are located. It won't cause a problem with moving that Operations Master role either. If you don't get follow-up from them by the end of the week you can reach out to me directly gregja at microsoft.com and I will make sure the right people at Microsoft get in contact with you.

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

tonymorev — Wed, 27 Mar 2013 15:25:31 GMT

Thanks again Greg! contacted sales via e-mail and also passed them a message via general support line operator. Waiting to hear back. Meanwhile did some additional reading on the things you pointed out. I must say some of the headaches of CA scared the ... stuff out of me .... "the location of the database must be the same", " the new server name must be the same, otherwise blah, blah, blah". Lucky for me i realized i'm not using CA at all :) we are to small to benefit from it, so i skipped it when i went with 2003 originally.

However reading the stuff reminded me of one peculiarity with my operations master. The machine was configured "late friday night" and because of some partitioning fluke ended up having an H: drive for it's system drive. I only caught it after the fact and because everything seemed to function Ok i left it alone. Later, in the best tradition of "making lemonade" out of anything that "hits the fan", i preferred to think of it as an added security benefit. Imagine a hacker trying to get through to a machine that has no C: drive. It works fine, even goes ok through updates and service packs. Of course i won't dare to do an in place upgrade, but in my situation it's not even possible. The question is, do you think it can still cause trouble during migration?

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

Greg Jaworski [MSFT] — Tue, 26 Mar 2013 15:09:33 GMT

@tonymorev For more information about becoming a Microsoft Premier customer email PremSale@microsoft.com. Tell them AskPFEPlat or Greg Jaworski sent you.

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

tonymorev — Tue, 26 Mar 2013 15:05:21 GMT

thanks Greg! Looks like i need to do some more reading. This is a huge help!

as for you last point ... how do we get Premiere Support (provided we find it affordable)?

i did a quick search for MS support options, but all i'm able to find on PFE is how to become one and how much you guys make :)

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

Greg Jaworski [MSFT] — Tue, 26 Mar 2013 00:00:51 GMT

@tonymorev

1) Once you have a number of 2012 DCs you can demote the 2003 DCs. If the DC is a FSMO holder you will get prompted to transfer the roles. However I would suggest that you manually do this as a planned event. The main one being the forest root PDCe since you will need to configure time properly for whatever DC is taking this role over. This is a good link for using a policy that uses a WMI filter to always ensure the forest root PDCe is pointed to an external time source blogs.msdn.com/.../configuring-an-authoritative-time-server-with-group-policy-using-wmi-filtering.aspx. Other concerns are roles on the 2003 DCs that need to be migrated. If a DC is also a CA it will not allow you to demote it and you will either need to migrate or decommission that CA. In a perfect world where DCs are nothing but DCs then yes they can simply be demoted. Yes I would recommended the functional level raise. You will receive many benefits of going from 2003 to 2012 including the Active Directory Recycle Bin.

2) I think you are referring to replicating the root which is not supported and not needed. You would add additional namespace servers to your DFS hierarchy and this data comes from AD and will be created on the additional namespace servers you specify. DFS-R will not replicate reparse points and there is some good information here blogs.technet.com/.../dfsr-reparse-point-support-or-avoiding-schr-246-dinger-s-file.aspx. I think that is what you are asking, but if I am not understanding your question please let me know.

3) I'm not 100% clear on your plan here, but I will say DON'T clone. That's a dangerous scenario and if you miss a step or get pulled in a different direction you could have big problems. Yes we strongly emphasize labs here. What you can do and what we frequently do is perform a forest recovery in a lab environment (ISOLATED) and use the recovered forest to do very SHORT-TERM testing of applications and our upgrade plan (schema, first DC......). This accomplishes two things....you have a backout plan if things go wrong in prod and you have an environment to test your upgrade. You should destroy this environment when you are done. I know that is extremely high level but this is too detailed a topic to cover in the comments. Do the lab testing that you need to do, and then in Prod implement a new VM, with a clean install of the OS, promote it to a DC and transfer the PDC FSMO. That is the safe supported way of doing it.

Hope that helps....if you have more questions or need more detail please respond in the comments...I don't know if the company you work for has Premier Support, but this type of engagement is one that we can help with.

Thanks,

Greg

re: Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)

tonymorev — Mon, 25 Mar 2013 16:01:41 GMT

Hi Greg! Great write up, very helpful and coincidentally just what I’m looking at doing.

A few follow-up questions if you don’t mind:

1) Once a 2012 DC is introduced, is it enough to just demote all of the 2003 DCs to make the new guy operations master, or are there extra steps needed to make my domain 100% 2012? Short of raising the forest functional level that is. And would you even recommend raising?

2) I use DFS a lot. From what I gather even 2008 won’t replicate DFS links with 2003, so 2012 is not going either. Will 2012 at least be able to present the AD published roots to my clients without any special effort on my part? And what else should I look out for dealing with DFS while moving my domain from 2003 to 2012?

3) There is a lot of talk around here about how labs are so important. My plan with 2012 is to go virtual for the PDC and physical for DC2. I’m also planning on lifting my current physical 2003 PDC into a virtual machine and attempting to introduce the new 2012 DC in a simulated environment. I’ll be using VMware as I’m more comfortable with it than with any other virtualization platform. The question is, what stops me from taking a (hopefully successful) simulation of new 2012 DC and introducing it life into my environment, provided I demote the virtual 2003 ahead of time and turn off it’s physical clone before powering up the 2012 DC in production environment? I can afford some brief downtime especially on the weekends. Is there anything I should be on the look out for? IP’s , MACs, DNS, anything?

thank you so much!