Life of an IT Pro Advisor @ Microsoft Canada : Active Directory

Infrastructure Optimization Tour '06 Landing page is live!

rclaus — Fri, 25 Aug 2006 06:40:13 GMT

In case you didn't catch my hints in this July blogpost, the first TechNet national tour is around Infrastructure Optimization and supporting Branch Office solutions.

The landing page went live yesterday - you can see it here if you like.

As always - more details can be found over at The Canadian IT Pro Blog...

The .local VS real DNS Top Level Domain naming question - SBS (Small Business Server)

rclaus — Mon, 06 Mar 2006 07:44:39 GMT

I just posted a lengthy discussion around the question that comes up when one installs Small Business Server and what to call your Active Directory domain. This has been a topic of discussion with a number of my friends and IT pros I’ve met while on the road whenever we discuss Small Business Server issues.

It’s not something to be taken lightly and it deserves a little more thought then just pressing “next” during the install process. Check it out over at the Canadian IT Professional blog. join in the discussion by posting a comment.

Ottawa TechNet Monthly (October 2005) Resource Page

rclaus — Mon, 31 Oct 2005 17:21:00 GMT

The first Ottawa TechNet monthly session on Advanced Active Directory Design was well received by the crowd that made it in on the 25^th… I am glad to see the interest is still there (and growing) to continue to have these sessions within the timeslot (12 to 1:30) that seems to work best for everyone. As discussed, Registration/Lunch will be from 11:30 until 12:00 (I will be in the room eating with you) with content starting sharply at 12:00 ending at 1:30 with a ½ hr “Tear Down and Q&A” for spill over conversations. It is my commitment to stick to this schedule and be there as a resource for you.

Speaking of resources, I decided to be a bit more proactive with my follow up after events I delver with regards to resources available online. This one is an easy one – for the Advanced Active Directory Design session there is only a couple of links I wanted to share with you..

The first link is for a copy of the slide deck… Here it is…

The second link is for my “in place migration methodology” that I have used on 30 or so of my past NT4 migrations to Active Directory. This article can be found here…

So there you go – I hope that you find the content useful.

Oh yeah – one more thing… I mentioned that I am trying something that was well received last year with regards to “series” concepts. The next Ottawa TechNet monthly will be the first in a series of 3 session targeted towards Group Policy… Each session will build off the previous session and will hopefully be as interactive as the crowd happens to be. So bring your questions, scenarios and GPO experiences and let’s share them with the group. Register today - here's the link to the events page!

As always - if you have something to say or want to leave a comment - click on the comment link to share it with the world.

AD to NT4 In-Place Upgrade - Wrap up (In-Place Migration - Part 8)

rclaus — Fri, 22 Apr 2005 14:28:00 GMT

This series was a lot of fun to write up. I enjoyed all your comments along the way, thanks for sharing them all with everyone that's following along.

I wanted to share some final thoughts and wrap up stuff with this series of posts. I haven't mentioned testing at all yet - mainly because it is a highly personal thing that has to be determined by your migration team - more on this in a bit. A couple of things I have learned throughout the refinement of this migration process;

Your chances of success are directly related to the level of management AND technical staff “buy in"
Get out there, share, communicate
Map technologies to business drivers to increase buy in
Create a clearly defined communication plan that is tailored to the appropriate audience

Testing procedures need to be developed, documented and checked. People have to "own" the tests and determine exactly what needs to be done for each test. These test plans then need to be tried out BEFORE the migration to ensure they work in the first place (you'd be surprised if I told you how many WEREN’T tested before hand and didn't work after). These tests will be performed after the migration and post migration configurations are complete. If they pass - you are a go. If not - you have to continue to troubleshoot to get them working.

Management and Technical Staff "buy-in" is critical in being able to work though or around any political roadblocks that come up along the way. You will need to be able to speak to the appropriate levels in the language they understand and satisfy their needs for this migration. Sometimes needs are actually benefits and goals directly related to what is important to them and what drives the business. You aren't doing this upgrade for the sake of technology - you are doing it to make your business more agile, reduce the amount of time and effort it takes to manage it which in turn will make your job easier by giving you more time to look after OTHER things that need your attention. Without buy-in - you aren't going to get far and you will be shackled to political decisions that just don't make sense.

The communications plan is also critical. Keeping the appropriate people in the loop along the process of the migration is very important.

Let's hear it for single domain forests! (where appropriate) Let's hear it for simplified AD designs!

NT4 to AD Upgrade - Post Upgrade Tasks (In-Place Migration - Part 7)

rclaus — Thu, 21 Apr 2005 15:22:00 GMT

Here are some more details on some post-upgrade tasks I have implemented in my In-Place Migration strategy for customers migration from NT4 to 2003. As I previously stated (and have to state once again) - this is not meant to be an exhaustive list, but rather a guide on what you should include in your in-place upgrade plans. As always - your mileage may vary - ensure you have a good plan in place and know what you are doing before proceeding.

What have we got now? An NT4 domain that has been in place upgraded with a temporary BDC. We have all new clean 2003 server installs now promoted to become DCs as well and we have distributed all the FSMO roles to the appropriate servers. We are running in mixed mode and things are just perfect. There has been minimal interruption to your end users (they couldn’t' change their password for maybe an hour at most and no new accounts or groups could be made) but that was only temporary. They could still log on and work as normal without any problems. Let’s finish this up.

Post upgrade tasks
OS upgrade your NT4 BDC machines and cancel the DCPROMO process on first reboot
I want to get out of mixed mode as soon as possible. Why? Because without Native Mode, I can't do nested Global groups and I still have to worry about replication with old BDCs. Besides - those old BDCs would look great in my test lab or as a new foot rest under my desk. Go ahead with an OS upgrade on these NT4 BDCs - again about 36 minutes or so for each box - but they can be done in parallel to speed things up. Once the first reboot occurs, they will auto logon and try to run DCPROMO. The first question it asks is if you want this machine to continue to be a domain controller - select NO and complete the wizard. It goes ahead and deletes the old role and reboots the system.

Shutdown old BDCs and remove their computer accounts from the new domain.
Once they come up from their last reboot - they are now Member Servers and can be safely shut down and deleted from the AD. If they are to be re-used, I suggest that you reformat and re-install Windows Server 2003 to get a clean install on the hardware and then add them back into the AD domain with new computer names.

Switch to native mode AD
The moment you have been waiting for - flip the switch (or rather change the drop down box) to Windows 2003 Native mode. This can be done form Active Directory Users and Computers or from the Active Directory Domains and Trusts MMC console. You won't have an impact on your users and your BDCs are no longer in existence.

Build OU structure
So you have your AD, you have all new Domain Controllers and you are now running in Native Mode. Now is the time to implement the power of AD by creating your OU structure. This could be created by hand or an LDIF file can be implemented from a previous lab exercise - your choice. It shouldn't be complex if you followed my KISS and NIRVANA principles for AD design.

Implement Administrative delegation strategy
Once you are in native mode, you can start to implement nested groups and cleanup that bloated DomainAdmins group that was migrated. You can create new global Groups and delegate out the rights as required for various users and then remove them from Domain Admins. It's very satisfying to see this take place, but once again - you have designed this strategy in your AD design and tested it in the first phase of your lab environment. Now is the time to clean up and regain control of your NT 4 administration nightmare.

Implement group policy strategy
Your group Policy testing took place in the first stage of the lab. I hope that you were using the GPMC and were able to export your policies. You can now import them back in to your production environment and have them applied to the OU structures you have just implemented.

Move Users, groups and Computer accounts into proper OU structures
Now that your delegation is in place and your GPOs are in place, it's time to move the users, Computers and Groups to your new structure and call it a day. Your existing systems won't notice they are part of an AD domain until they have to renew their computer security connection. A reboot or patience will fix this. Soon enough you will have your GPOs humming and applied to your systems.

Welcome to the wonderful world of AD and all it entails. Any final comments before my final post on this In-Place migration series? Click on the Feedback/Comments link at the end of this post to make sure you are heard.

Stay tuned to the next post in this series - Wrap up Tomorrow!

NT4 to AD Upgrade - Upgrade Tasks (In-Place Migration - Part 6)

rclaus — Tue, 19 Apr 2005 15:17:00 GMT

Here are some more details on some upgrade tasks I have implemented in my In-Place Migration strategy for customers migration from NT4 to 2003. As I previously stated - this is not meant to be an exhaustive list, but rather a guide on what you should include in your in-place upgrade plans. As always - your mileage may vary - ensure you have a good plan in place and know what you are doing before proceeding.

Before proceeding it is important to note that I assume that you are not running any mission critical applications or file shares off your domain controllers. As well - if you have infrastructure services running on these systems (like DNS, WINS or DHCP) you have a plan on how to move or update the services once the migration is complete or better yet - before you even begin. You can always come up with a strategy to keep them on the same systems or move them to the new hardware ahead of the migration day. I personally recommend that you move the infrastructure services OFF the old PDC/BDCs ahead of the migration and also swap IP addresses with the new machines ahead of time. That way you DON'T have to revisit all your client systems (to update DNS or WINS server entries) and you take as much work OFF the migration team and spread it out BEFORE the migration night. The less stuff you have to do on the migration night - the better.

Upgrade tasks
Swap PDC/BDC roles
This part is quite simple. You go into server manager and select the "temporary BDC" and choose promote to primary. This will result in a brief period of server interruption where people will not be able to change their passwords. It will not prevent them from login on and your users shouldn't notice that anything is going on at all. Once this is complete - ensure the WINS server entry is updated (you can do a net stop netlogon and net start netlogon to help it along or even a nice reboot). Once this is done - this can be used as a backout / rollback process. How? Say the upgrade fails for some reason - you still have your old PDC and BDCs running NT4 and doing nothing in regards to the upgrade as of yet. All you do is turn off the temporary PDC/BDC and promote the old guy back again - you are back to normal.

Double check WINS entries for new PDC role
Did I mention this was important? Without a proper 1B and 1C records registered for the domain, the backup domain controllers won't upgrade and your migration will stall. Check your wins database with the WINS manager. Also - in my previous post I warned about LMHOST files - are they present for some reason? If they are - update them to reflect the new PDC.

OS upgrade "temporary BDC" to 2003
Pop in the CD and off you go. Upgrade the OS (takes about 36 minutes or so based on your hardware of the Temporary BDC) and on the first reboot it will auto logon and start the DCPROMO process. You might get compatibility errors on drivers or whatever and might have to locate the appropriate drivers before continuing - no problems, you would have discovered these in your testing lab, right?

On reboot - complete the DCPROMO wizard to create your new AD forest and domain
You can either be a new domain in a new forest or you can join an existing forest as a new domain. You can not become an additional Domain controller for an existing domain for obvious reasons. Choose the default location for most of the things like database, logs and sysvol (all NTFS partitions) because this is only a temporary 2003 Domain Controller. The cool thing (ok, I think it is cool) is that you will see the number of object that have been created and migrated from your old environment as the migration wizard runs. It's just cool. At the end of the upgrade process, it will reboot once more and come up for the first time as an AD Domain Controller (DC). Congratulations, you have your first AD upgrade in place (excuse the pun). From the time the NT4 OS requires the first reboot to continue until the time that the server comes up for the first time, your users will not be able to change their password.

Logon and review event logs on Temporary BDC
Now is when you go in and check out the event logs and ensure everything came up ok and things are humming along. You will get warnings that the server can't connect to various FSMO roles or issue RID pools - this is normal for the first time up and after a couple of minutes, you should see the next event log entry that states all is well. I generally wait about 10 - 15 minutes or so after the first reboot to let things simmer nicely.

DCPROMO 1 or more of the X 2003 member servers to be new DCs
As soon as possible - get the member servers DC Promo'ed by either physically standing in front of them and running DCPROMO or Remote Desktop Connection to them and do the deed. This will prevent all your Windows 2000, Windows 2003 and Windows XP based machines from "piling on" to your single 2003 Domain Controller. With your member 2003 servers in place ahead of time - you can easily RDP into them and DCPROMO during the same upgrade session!

Complete FSMO role transfer and other things from "temporary BDC" to final FSMO role holders
So you have this temporary BDC now as your King Domain Controller (that's a Rick term) and you need to spread the FSMO roles from him to the real production domain controllers in order to safely remove him from the role of DC and remove him from the domain - he is "temporary" after all and has been upgraded from NT4 to 2003. The FSMO transfer process is accomplished by using the NTDS utility with the appropriate Enterprise administrator rights. This is a well documented procedure that can be found in the Microsoft Knowledge base (http://support.microsoft.com/kb/255504). Your AD design document would outline where the FSMOs should be sitting and it's a simple process to do the actual move. Rather un-exciting, but required.

Would you add anything to the actual upgrade tasks? Click on the FeedBack/Comments link at the end of this post so we can all hear what you have to say.

Stay Tuned for the next post in this series on Thursday, April 21st.

NT4 to AD Upgrade - Pre-Migration Tasks (In-Place Migration - Part 5)

rclaus — Thu, 14 Apr 2005 15:32:00 GMT

Here are some more details on some pre-migration tasks I have implemented in my In-Place Migration strategy for customers migration from NT4 to 2003. This is not meant to be an exhaustive list, but rather a guide on what you should include in your in-place upgrade plans. As always - your mileage may vary - ensure you have a good plan in place and know what you are doing before proceeding.

Pre-Upgrade Tasks
Install x number of new 2003 Member servers as part of your NT4 domain
These servers will be your final production AD domain Controllers (DCs). Notice they are introduced early in the game as fresh install and tweaked 2003 member servers working in your NT 4 domain? They will house your new crisp and clean AD directory and will never have had any legacy NT 4 parts on them what so ever. They will have all new and signed windows 2003 Server certified drivers and all the latest patches installed to the operating system. Because they are member servers - they can be introduced any time in the pre-upgrade process. I've even implemented these with remote desktop enabled at remote sites in multiple provinces in order to minimize travel of having to be right in front of the servers for the actual DCPROMO process.

Backup all your domain controllers
This is obvious - it's one of your restore points that you can use if you so choose to backout. Make sure the backups worked and are verified. I've even gone through the steps of a single drive that was part of a mirror and replacing it with a new drive and allowing it to rebuild as a second layer of "protection"

Doublecheck for LMHOST files
I've gotten burned by this one early on - and it's now in all my pre-checks. You might have implemented a custom LMHOST file that hard codes IP addresses and roles to specific machines (the 1B and 1C NetBios names that represent domain controllers and PDCs in an NT4 environment). Just be sure you know where they are and how to remove or edit them according to future steps in this migration process. This might seem trivial, but it’s tough to troubleshoot name resolution when a Backup Domain Controller can't locate its PDC anymore and therefore won't continue with an OS upgrade.

Ensure WINS and DNS configuration
Also a gotcha here as well. In future steps, you will be swapping the role of PDB and BDC and you will need to know how to locate the 1B and 1C records to verify they are been registered correctly and they have replicated correctly. You might not have known that your WINS replication was "hurting" in the first place... Get it identified and fixed now before migration day comes.

Introduce "offline BDC" into your production environment
This is another point of backup or rollback that you can do. Bring up an NT 4 BDC and make sure it syncs with the PC. Take this guy offline and put a post it note on him identifying him as the back out machine and a big DO NOT TOUCH OR PLUG IN Warning on it.

Introduce "Temporary BDC" into your environment
My process is one where a temporary NT4 BDC is introduced and does the actual work of the migration. Once it's complete, the new clean 2003 REAL production servers (which are currently member servers) are integrated, tested and configured. Once they are driving the AD, this guy is expendable. DON'T just turn him off - you have to DCPROMO him back down after the process is complete in a future step. I’ve used both higher end new desktops and even a virtual machine for this guy in previous projects - use whatever class of system you can afford and are comfortable with - it won't be around for long.

Now - Pick your date - you are ready to migrate.

Did I miss something? Have you done something different? Click on the Feedback/Comment link at the bottom of this post to tell me about it.

Stay tuned for the next post in this series on Tuesday April the 19th.

In-Place NT4 to AD migration recipe for success! (In-Place Migration - Part 4)

rclaus — Tue, 12 Apr 2005 15:24:00 GMT

Is this the fourth post already? WOW.

So what are the nuts and bolts of my modified In-place migration process I have used on almost all of my AD Design and migration projects? Let's be brief and describe it here (I'll try my best) and expand each of the three sections in three more posts.

Pre-Upgrade Tasks

Install x number of new 2003 Member servers as part of your NT4 domain
Backup all your domain controllers
Doublecheck for LMHOST files
Ensure WINS and DNS configuration
Introduce "offline BDC" into your production environment
Introduce "Temporary BDC" into your environment

Upgrade tasks

Swap PDC/BDC roles
Double check WINS entries for new PDC role
OS upgrade "temporary BDC" to 2003
On reboot - complete the DCPROMO wizard to create your new AD forest and domain
Logon and review event logs on Temporary BDC
DCPROMO 1 or more of the X 2003 member servers to be new DCs
Complete FSMO role transfer and other things from "temporary BDC" to final FSMO role holders

Post upgrade tasks

OS upgrade your NT4 BDC machines and cancel the DCPROMO process on first reboot
Shutdown old BDCs and remove their computer accounts from the new domain.
Switch to native mode AD
Build OU structure
Implement Administrative delegation strategy
Implement group policy strategy
Move Users, groups and Computer accounts into proper OU structures

What was my worst case scenario that this method has gone through (and survived)? Remember - I've never had to roll back yet! I've implemented this on a client of 3500 users in 10 physical sites with the DCs centralized. The process started on Saturday morning with the team getting a Processor failure on the PDC, hard drive issues on one of the BDCs, WINS replication errors, hard coded LMHOSTS files, a fire alarm that required evacuation and top it all off with a winter blizzard that shut down the airports and prevented a Microsoft Consultant (who shall remain nameless) from showing up until the next day after the migration process was completed. It worked through all of those issues AND it was completed WITHOUT informing the user population that it was taking place (team choice that I now personally recommend).

On the Monday after the migration, we found out that there were over 300 logons via remote access and "in-building" weekend workers and NOT A SINGLE helpdesk call or service outage issue reported. Not bad eh?

Have you had any bad experiences with a migration project and had the procedures in place to handle them? Tell me about them by using the Feedback/Comments link at the bottom of this post!

Stay tuned to the next post in this series on Thursday April 14th.

Creating the Lab environment for your AD (In-Place Migration - Part 3)

rclaus — Thu, 07 Apr 2005 15:41:00 GMT

This post will deal with the mechanics of creating a representative test lab and getting the procedures documented just right. Please be forewarned - this process is not something that is cookie-cutter fitting to each migration project I worked on for the last 5 years. It is adaptable to each client I worked with in order to ensure all their needs and concerns were met. You will have to take the basis of these posts and apply it to your own environment to make sure you are well served by its overall use.

Most labs that I've created worked for two purposes. One was created early on to document the design pieces that had to be in place to support the final end point of the AD design. The other was to document the actual migration process.

The first Lab phase is one that was created based on the AD design Endpoint and is useful to share with management and non project IT staff who are not Migration or Design team members to allow them to kick the tires and provide feedback on how the design will work in the new environment (i.e. Buy-In!!!) They could see delegation working, sample GPOs tested out, inheritance flowing down OU structures - you name it. It's a show and tell lab for what the new environment will be like. It's an extremely valuable tool to get buy in from all the levels in an organization if you can have something they can see, feel and touch - rather then just having the design document to read. It also is useful in order for you to document your post migration procedures for implementing your design. This includes things like script creation to make the OU structure, administrative delegation strategies, sample GPO settings to implement right after migration, new helpdesk and administrative procedures - the list goes on and on.

The second lab phase is built to represent your current state and is then used to document the procedures required to get you migrated. This includes as many safeguards for rollback as you comfortably require mitigating any risk you identify. I can happily say that I have never had to roll back any migration I have designed or implemented in my 5+ years of doing this. (Do it right, do it once!) For this lab to work, you need a temporary BDC created in your production environment that you can pull into your lab environment (don't forget to delete this temporary BDC from your SAM before migration) This temporary BDC will be maintained in your isolated lab and promoted to become your lab PDC and hold a real copy of your live SAM database. Whoa down there - Security concerns? No problem. Change all the passwords in front of your security officer so that they can't be compromised. It also facilitates user testing in future stages. I've used a script that resets EVERYONEs password (in the lab environment while logged on to the server with administative rights) to a complex password and run it against the database – just to show the Security Officer that we weren’t using the backup copy of the SAM as a cracking exercise. :)

You then need to bring in or re-create your infrastructure (DNS, DHCP, WINS) and required testing services (maybe a LoB app or Web based application that is critical). This will require other IT staff members that might not be too forthcoming to help re-create something in your test lab. How do you sell this? It's their chance to ensure their application will continue to work post migration - rather simple, eh? Go as big or as minimal as you feel is required.

So by now we're up to anywhere from a couple of servers to a datacenter number of servers in your test lab. What? Don't have the cash for this? You told me you had endless cash available for this project! No worries - two things to help out here. I am usually able to make the pitch that new domain controllers will be required for the new migration. If this is the case for you - secure them ahead of time in order to use them for your lab. Still not enough? Have you considered Virtual Server 2005 as a solution? It can take systems and patch them into multiple virtual networks or physical networks with great speed and ease - the REAL benefit is the undo disks. You can "reset" your lab back to the way you started by only choosing "shutdown and discard undo disks" option on the Virtual machines. WOW - Virtual Server ROCKS! It used to take DAYS to do that before... Did I mention I am a BIG fan for Virtual Server 2005?

Did you need to get Phase One lab back for some reason? Just boot up the virtual machine files as required to have a second look. When you're done, bring back the second phase lab to fine tune the migration again. Once the migration is finished - you have a representative test environment that you can use to test and implement new changes to your infrastructure BEFORE bringing them into production.

I can't stress the importance of getting a good representative lab in place for both "buy in - kicking the tires” of your new design AND for the actual migration step by step procedures. You will actually find the night of the migration rather uneventful and anti-climactic since you would have rehearsed and planned almost all the steps and come up with contingency plans on what to do if something fails.

What do you think of this lab environment? Do you have one? Click on the Feedback/Comments to sound off on this post and tell me what you've got or what you've done to make your migration successful. Stau tuned to next Tuesday (12th of April) for the next post in this series!

How much of an AD design required before a migration? (In-Place Migration - Part 2)

rclaus — Tue, 05 Apr 2005 14:12:00 GMT

OK. So I have struck a nerve with my In-Place Migration series post. You've asked me to clarify my thoughts on what makes up an AD design. I thought I wasn't going to get into AD design, but I feel I must - at least a bit - in order to make this series of posts flow. I left the consulting side of things for my new post at Microsoft Canada because I was getting tired of all the deliverables and paper documents I created. I've killed my fair share of trees in this line of work as an AD design and migration guy. People ask me "How much of a design document is required?" - the answer - it depends on your audience. I would take great care in determining if the audience for EACH document was technical, executive or even end-user. Each document would be tailored to the audience to ensure that it could be digested and understood for what was important to them. Obviously, the contract and the customer dictates the # of deliverables, format/medium and approximate brick thickness - but I would take the extra time to ensure the audience was kept in perspective at all times. I've done AD design documents that are as short as 15-20 pages or as long as multiple hundreds. One thing you WON'T find in my documents is ENDLESS pages of screenshots - carefully selected ones are quite useful. Maybe it's just me, but do you need to show every screenshot for a migration process including the next button on a multi page wizard? I had to review (and fix) a number of competitors AD design documents on a number of occasions and I was astounded at the number of screenshots. But I digress...

How much of an AD design is required to start this migration process? The classic consultant answer - it depends. Most migration designs that I worked on included an AD design that had the following components completed. The level of detail and the number of sections was directly tied to the audience. Also - THIS IS NOT AN EXHAUSTIVE LIST - you might require more information then what is listed below. These are only "talking points" in what I would include in an AD design document. Don't be scared of the list - some sections were as small as a paragraph, but others were quite long.

Review of existing environment (# domains, PDC/BDC placement, HW inventory, IP configuration, Trust relationships, User Rights, Administrative Group memberships, # global groups, Infrastructure services (DHCP, DNS, WINS), Login scrip review, System Policy review)
Logical Design (# forests, Domains, Password / audit policy, Domain controllers & Global Catalogues, FSMO placement, OU structure, Administrative delegation strategy, User/group placement in OUs, Computer/Server placement in OUs)
Physical Design (site definitions, subnets, DC and GC placement)
Server Design (DC hardware specs, GC hardware specs, DB placement, Sysvol placement, IP configuration)
Infrastructure design (DNS strategy, DNS server placment, WINS, DHCP)

The Nice to have stuff - but not required for the migration.

Group Policy design for Servers, Desktops / Laptops
Group Policy Strategy for administration
Updated Administrative delegation policy
DFS configurations
Workstation design (image deployment methods, application deployment strategy, application packaging)

I would find that people were not so interested in the review part, but after it got underway - they realized the impact and value of having all the information in hand when it came time to complete the design portion.

What do you think - missing anything yet? I could throw you the link to a number of Microsoft white papers on AD design, but I will let you discover them (unless requested in the comments :) ). As always - click on the Feedback/Comments link at the end of the post to speak up and be heard. Hey - you can now even RATE the post.

Check back on Thursday for my next post in this AD Design series!

Slide Decks and resources - Diapositives et ressources (TechNet Winter/Hiver 2005)

rclaus — Sat, 19 Mar 2005 15:41:00 GMT

Les diapositives sont maintenant disponibles en français. Voici le lien pour le site de web ou tu peu les télécharger.
http://www.microsoft.com/technet/canada/wintertour2005/postevent/default.asp

J’ai aussi inclus le lien pour un article j’ai écrit ou il y a beaucoup de ressources et logicielles que j’ai utilisé pendant les séances.
http://blogs.msdn.com/rclaus/archive/2005/02/24/379540.aspx

Merci tout le monde pour un tourné de TechNet qui était vraiment « fun ». On va avoir un rencontre avec l’équipe pour décider comment améliorer la prochaine tournée.

-------------

The slides have been available for a while on the post event web resource page. Here is a link to the official post event site.
http://www.microsoft.com/technet/canada/wintertour2005/postevent/default.asp

I’ve also included a link to an article that I published earlier in the tour that has links to all sorts of utilities and evaluation software you can download and try for yourself.
http://blogs.msdn.com/rclaus/archive/2005/02/24/379540.aspx

Thanks goes out to everyone for making this TechNet tour so fun. I had a great time and can’t wait to have a post tour pow-wow and discuss how to make the next one even better!

As-tu des problèmes avec un erreur « [strings] section is too long » quand tu travailles avec un GPO?

rclaus — Wed, 16 Feb 2005 20:20:00 GMT

J’avais beaucoup de questions dans mon courriel électronique au sujet d’intégrer les nouveaux *.ADM fichier qui sont en place avec Windows XP SP2 dans une environnement Active Directory. Peut-être j’aurai beaucoup d’autre question maintenant que les personnes travaillent avec Windows Server 2003 SP1. Les deux systèmes changes la longueur des « strings » au point qu’ils sont incompatibles avec un MMC qui est utilisé sur un system au niveau précédent de Windows XP SP2.

J’ai déjà écrit un article qui explique la méthode que les *.ADM fichier se mis a niveau automatiquement dans un environnement d’Active Directory et comment tu as besoin d’évaluer et choisir la procédure qui est correct pour votre environnement. (La manière défaut fonctionne pour presque tous les gents)

Pour essayer de répondre au question la plus simple et le plus court que possible :
Si tu crée ou change un GPO avec un MMC sur un system de Windows XP SP2 ou Windows Server 2003 SP1, la réaction défaut est que les fichiers seront télécharger au Domain Controllers et en effet remplace les versions plus ancienne. Pour éviter les erreurs de « [strings] too long », toutes les systèmes utilisés pour gérer les GPO a besoin d’un patch pour mettre a niveau un DLL qui est utiliser par le MMC.

(Cette réponse est simple et court?)

Regarder l’article KB842933. Il est trouvé ici. Tu n’as pas besoin beaucoup d’analyse pour cette patch. Les systèmes n’ont pas besoin d’être redémarré après l’application du patch si tu fermes le MMC avant de commencer. Seulement les systèmes utilisés pour gérer les GPO on a besoin du patch. Les systèmes au niveau de :

Windows XP sans SP2
Tous les systèmes Windows 2000 Professional
Windows Server 2003 sans SP1
Tous les systèmes Windows 2000 Server

Si tu décide de ne pas appliquer le patch – c’est OK – tu ne casse pas ton GPO si tu les changes avec un MMC plus ancien. Tu dois tous simplement « clicker » un vingtaine fois sur le « ok » bouton. ;-)

Perplexed with a "[strings] section is too long" error when editing a GPO?

rclaus — Fri, 11 Feb 2005 16:23:00 GMT

I've had a number of questions around the *.ADM templates that come with a Windows XP Service Pack 2 machine and what they do to the GPOs in an Active Directory Domain. With people using Server 2003 SP1 systems, I might get more questions being asked. Both systems increase the length of strings beyond what the MMC console can take on a older OS (by older I mean PRE-XP-SP2).

I've already wirtten an article outlining the ADM template update process, how they get copied up to the domain controllers AND about how you need to choose the right process for your organization - default works great for almost all situations.

To make a long blog post shorter and to come to the point:
If you edit a GPO with an XP-SP2 or Server 2003 SP1 management console with the updated *.ADM templates, the default action is that the templates will be copied up to the Domain Controllers and overwrite the old ones. As a result of this action - all admin workstations (and servers) that are NOT XP-SP2 or Server 2003 SP1 need to be patched with the appropriate patch if they are going to be used to manage GPOs.

(that was short?)

You might want to read the details contained in Knowledge Base article 842933. It can be found here. Not to worry - no major testing require of this patch. No reboots are required (unless the GPO MMC or GPMC is open at the time of the patch - in which case, close it and patch again). Only the systems used to manage GPOs need to be patched. They apply to workstations that are running:

Windows XP PRIOR to Service Pack 2
All Windows 2000 Pro systems
Windows Server 2003 PRIOR to SP1
All Windows Server 2000 systems

If you don't patch them - don't worry - you won't "break" your GPO by editing it with an older version of the console. You'll just have to be proficient at clicking 20 or so times on the OK button. ;-)

DNS - Les stratégies de noms de domaine pour AD (Active Directory)

rclaus — Tue, 25 Jan 2005 16:33:00 GMT

Le nom de domaine de DNS est fréquemment un bloc dans le processus de conception pour des personnes travaillant sur une migration d'AD. J'ai fait un certain nombre de « round tables » ou les discussions facilitées au sujet de ces matière et ce qui me surprise est que les gents le fait plus compliqués qu’ils on besoin. Étant un conseiller qui a fait un certain nombre de projet d'AD pour des clients avec les nombres d’usager de 200 à 27000 je l'ai vu tout. J'ai deux recommandations simples :

Utilise le principle de KISS (Keep It Simple S{remplace le mot avec ton nom de choix})
Fait le choix correctement un fois - et gardez-le.

La semaine passé, j'ai sorti pour le dîner (j'étais à Redmond pour une conférence technique) et une discussion a été soulevée au sujet du stratégies de DNS. Prenez un consultant en matière de stratégie d'entreprise, un consultant d’AD et un x-RedHat/Ingénieur d'oracle et quelques points intéressants obtiennent augmentés. Je ne vous dirai pas qui a soulevé quelle stratégie - je vous laisserai choisir:

Option 1 - Employez les mêmes noms internes et externes.
Si j’ai déjà achetez rickcompany.ca. et je l'emploi a l’extérieure, pourquoi pas employez a l'intérieure aussi? Humm... Maintenir 2 zone de DNS sur deux serveurs qui ne peut pas échangez l'information et devront être séparément contrôlés. Ceci pourrait sembler comme un bon principe de KISS et fortifier le « confort » des clients interne. En effet - il place beaucoup plus d’effort administratif sur les admins de DNS et ce n'est pas exactement « future proof » pour les besoins changeants d'affaires. Vous devrez manuellement ajouter les entrées externes dans votre zone interne. Vous devrez sélectivement ajouter les ressources internes à votre zone externe. Comment manipulerez-vous les ressources internes et externes quand c’est temps de changez a IPv6?

Oui – c’est vrai. Je l'ai mise en application cette stratégie pour des clients - après qu'ils aient passé en revue tous les « pour et contre ».

Option 2 - Employez un domaine secondaire délégué du domaine externe pour le domaine interne.
Si j’ai déjà achetez rickcompany.ca et je l'emploie a l’extérieur (je l'accueille sur un ensemble de serveurs moi-même ou mon service d’Internet), je crée un domaine secondaire a l’intérieur seulement qui pourrait s'appeler corp.rickcompany.ca ou ad.rickcompany.ca ou n’importequoi.rickcompany.ca. Puisque ce domaine secondaire est seulement maintenu a l’intérieur sur les serveurs internes de DNS, il ne peut pas être accidentellement placé sur les serveurs a extérieur. Les clients et les serveurs feraient partie du domaine secondaire interne de rickcompany.ca et fonction normalement dans un environnement d'AD. Si vous aviez déjà une grande (ou petite) zone de DNS rickcompany.ca, les ressources pourraient être transférés à l’intérieur utilisant un zone secondaire. C'est le plus facile à contrôler, puisque vous commandez la zone et ne devez pas s'inquiéter de ce qui est à l'intérieur et dehors. Vous « futureproof » également votre réseau, puisque vous avez des noms uniques à l'intérieur et a l’extérieur. Si vos clients internes ont la mauvaise habitude d’identifier les ressources pas entièrement qualifier de DNS, vous pouvez ajouter rickcompany.ca à votre liste de domaines de recherche pour assurer le nom résolution approprié.

Option 3 - Employez un domaine interne non standard. (Dustin Norman m'a rappelé celui-ci).
J'ai employé celui-ci à seulement une occasion. Je vous avertis que vous devriez employer celui-ci avec prudence - comme il limite sévèrement votre capacité de contrôler facilement les ressources internes que vous voulez faire accessible à l’extérieur. Si vous choisissez d'employer rickcompany.interne ou rickcompany.local pour votre Domaine interne de DNS, vous garantissez pratiquement que vos centres serveurs internes ne seront jamais résolubles du monde extérieur. Il n'est pas dans généralement de meilleures habitudes recommandées d'employer ce type de domaine non standard de DNS sans regarder toutes les implications.

Je terminerai cette conversation en disant – comprenez toutes les implications de choisir le nom du domaine de DNS. Choisissez seulement après que vous avez évalué tout les options. Vous avez besoin d'un stratégie en bon état pour votre nom de domaine DNS et comment cela fonctionne afin d'assurer une base forte pour « Active Directory ».

Comment est-ce que je réponds quand quelqu'un me pose la question de DNS? "Ca dépend....."

Voici un lien à la discussion 2003 de guide déploiement des serveur DNS de Windows
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dnsbd_dns_tvnd.asp

DNS Naming Strategies for AD (Active Directory)

rclaus — Mon, 24 Jan 2005 20:30:00 GMT

DNS Namespace is frequently a stumbling block in the design process for people working an AD implementation or migration. I've lead a number of roundtables or facilitated discussions about this topic and I frequently find that people make it way more complicated then they need to. Being a consultant who has done a number of AD designs for customers ranging in size from 200 to 27000 users, I've seen it all. I have two simple recommendations:

Use the KISS principle (Keep It Simple S{fill in appropriate word here}
Do it right once and lock it in.

I was out last week for dinner (I was in Redmond for a technical conference) and a fairly heated discussion came up about DNS Naming Strategies for Active Directory. Take an x-enterprise strategy consultant, AD design consultant and an x-RedHat/Oracle engineer and throw them the DNS naming strategy topic and some interesting points get raised. I won't tell you who raised which strategy - I'll let you make your own.

Option 1 - Use the same Internal and External domain names.
If I already own rickcomapny.ca and I use it externally, why not use it internally as well? Humm... Maintain 2 DNS zone files on two servers that will from this day forward never exchange information and will need to be separately managed. This might seem like a good KISS principle and minimize internal client "comfort" of not having to change DNS namespace. In actual fact - it places much more administrative burden on the DNS admins and is not exactly "future proof" for changing business needs. You will have to manually add external entries into your internal zone. You will have to selectively add internal resources to your external zone. How will you handle internal and external records when you transition to IPv6?

I'm not knocking this method - I've implemented it for customers in the field - after they have reviewed all the Pros and Cons.

Option 2 - Use a delegated sub domain of the external domain for the internal domain.
Once again - if I own rickcompany.ca and I use it externally (either I host it on a set of servers or my ISP hosts it), I create a sub domain internally only (at this time) that could be called corp.rickcompany.ca or ad.rickcompany.ca or whatevermakessense.rickcompany.ca. Because this sub domain is only maintained internally on the internal DNS servers, it can't be accidentally placed on the outside servers. Clients and servers would be part of the internal sub domain of rickcompany.ca and function as normal in an AD environment. If you already had a large (or small) DNS zone of rickcompany.ca, the records could be transferred internally as secondary zones and maintained on which ever servers required the zones. This is by far the easiest one to manage, since you control the zone and don't have to worry about what is inside and outside. You are also futureproofing your design, since you have unique names inside and out. If your internal clients have the bad habit of not fully qualifying resources in the rickcompany.ca domain, you can add it to your list of search domains to ensure proper name resolution.

Option 3 - Use a non-standard internal domain. (Dustin Norman reminded me of this one).
I have used this one on only one occasion. I warn you that you should use this one with caution - as it severely limits your ability to easily manage externally accessible internal resources. If you choose to use rickcompany.internal or rickcompany.local as your internal DNS domain name, you virtually guarantee that your internal hosts will never be resolvable from the outside world without jumping through hoops. It is not generally a recommended best practice to use this type of non standard DNS domain naming convention without looking at all the implications.

I'll end off this conversation by saying - make sure to understand all the implications of DNS naming convention. Only after you have evaluated all the options should you make your choice. You need a rock solid understanding of DNS and how it works in order to ensure a strong foundation for AD and name resolution.

How do I answer when someone asks me the naming question? "It depends....."

Here's a link to the Windows Server 2003 Deployment guide discussion on DNS naming conventions.
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dnsbd_dns_tvnd.asp