Tag Archives: Active Directory

It’s time for something different. As my time to write has been heavily limited in recent time, I figured that I might share articles that have peaked my interest. Here is the first post in my new “Share” series.

Active Directory has all its ins and outs. The problem sometimes comes in understanding the differences between items that look alike. Here is one that often gets overlooked. Password resets vs password changes. Is there a difference? Yes there is. And it is something that should be understood.

I hope you like this article. It is short and to the point, but it is a solid article. And no, this isn’t a plug for WebAD products, as I have never used them.

So something that doesn’t seem to be getting much press is that Windows Server 2012 brings safe virtualization and protection from USN rollbacks. Yes, it does. All the docs say it, but Hyper-V 3.0 and PowerShell V3 get all the press.

Windows Server tried to detect USN rollbacks, but this error… which can kill a domain was really a real danger: and regularly occurred. The more common ways a USN rollback might not be detected are: a virtual hard disk may be selected on more than one machine or more commonly, a snapshot of a VM is restored and it has an USN that has increased past the last USN that the other domain controller has received.

So while the first scenario might lead to domain controllers not replicating changes… and make things unstable and unpredictable, and kill your forest; the second can be really bad. Lets just say bad. Best case is an Event ID 1988 in Event Viewer for a lingering object. Sometimes though you have corrupt data and wipe out the domain.

So, what mas my mantra again? Oh yeah. Let’s make the new modeus operendi: just say no to “blowing up” your Active Directory. So give Windows Server 2012 a spin and let’s hear some attempts to kill it.

An excerpt from Microsoft discusses the new feature. Don’t forget to follow the link and read the whole thing.

Excerpt from http://technet.microsoft.com/en-us/library/hh831734.aspx

“Virtual environments present unique challenges to distributed workloads that depend upon a logical clock-based replication scheme. AD DS replication, for example, uses a monotonically increasing value (known as a USN or Update Sequence Number) assigned to transactions on each domain controller. Each domain controller’s database instance is also given an identity, known as an InvocationID. The InvocationID of a domain controller and its USN together serve as a unique identifier associated with every write-transaction performed on each domain controller and must be unique within the forest.

AD DS replication uses InvocationID and USNs on each domain controller to determine what changes need to be replicated to other domain controllers. If a domain controller is rolled back in time outside of the domain controller’s awareness and a USN is reused for an entirely different transaction, replication will not converge because other domain controllers will believe they have already received the updates associated with the re-used USN under the context of that InvocationID.

For example, the following illustration shows the sequence of events that occurs in Windows Server 2008 R2 and earlier operating systems when USN rollback is detected on VDC2, the destination domain controller that is running on a virtual machine. In this illustration, the detection of USN rollback occurs on VDC2 when a replication partner detects that VDC2 has sent an up-to-dateness USN value that was seen previously by the replication partner, which indicates that VDC2’s database has rolled back in time improperly.

A virtual machine (VM) makes it easy for hypervisor administrators to roll back a domain controller’s USNs (its logical clock) by, for example, applying a snapshot outside of the domain controller’s awareness. For more information about USN and USN rollback, including another illustration to demonstrate undetected instances of USN rollback, see USN and USN Rollback.

Beginning with Windows Server 2012, AD DS virtual domain controllers hosted on hypervisor platforms that expose an identifier called VM-Generation ID can detect and employ necessary safety measures to protect the AD DS environment if the virtual machine is rolled back in time by the application of a VM snapshot. The VM-GenerationID design uses a hypervisor-vendor independent mechanism to expose this identifier in the address space of the guest virtual machine, so the safe virtualization experience is consistently available of any hypervisor that supports VM-GenerationID. This identifier can be sampled by services and applications running inside the virtual machine to detect if a virtual machine has been rolled back in time.”

Do you have a broken glass account? Are you ready for your environment to survive if you are not there anymore? Do you consider the hit by a bus concept to be a joke?

So I am sure you all have heard of the old “hit by a bus” concept. This is the idea that in case something happens, there is documentation on running the network somewhere. This somewhere is known by the company’s management… and normally more than one member of that management.

Okay, so you knew the concept, but it is kind of joked about in the industry yes? Yes it is, by people who have never been there. My first example of needing this in my day to day work was when a Domino Administrator went hosteling in the nineties. He left, and the company had problems. And of all the security had been done just to him, not to a group… so no one else had access. Back then we could use a brute force hacking program and get in. We still can if you don’t do your job on passwords. But if you do… how do you get in to support? This last year I have ran across two clients who primary network people really did die. Some of the documentation was there… some wasn’t. Happily, a “broken glass account” was not needed.

So what is a “broken glass account”? The name comes from the old fashioned breaking of the glass to pull a fire alarm. What it means in information technology is a little different. It refers to an account that is documented with user name and password, and normally kept on paper in a safe that allows a person who does not have access privileges to gain those access privileges when necessary.

This allows you to keep auditing clean by not leaving active users passwords written down, and at the same time allow access at need. Auditing should never be endangered by sharing accounts. This just leads to suspected troubles later down the way. This is also partly the reason that designated “broken glass accounts” exist. If the engineer or administrator writes down their credentials, then forever more you cannot guarantee that only that person has access to that account. Instead you have guaranteed that is not the case.

This leads to one requirement to always put on “broken glass accounts”. You should require all “broken glass accounts” to have a requirement to change passwords on use if they are domain accounts. This updates the object in Active Directory and therefore begins an audit trail. And after any disaster there is likely to be a review, so bright and clear audit trails are important.

Now traditionally there is a twist to keep things a little more organized. You can keep tiers of accounts. Would I keep all that I list? No, but these are reasonable. I would keep two or three at most. I always start with Enterprise Administrator. Some reasonable tiers are:

Enterprise Administrator

Systems Management / System Center Infrastructure Engineer

Server Operator

Desktop Administrator

The broken glass account is part of a broader solution of business continuity and disaster recovery, but it is simply basing pre–staged emergency user accounts in secured location that will allow management to access them at need, while not breaking the audit trails. Just remember to keep this solution simple. If you do it will always be effective and reliable if something happens.

So, when you are looking at hiring or being hired in you will always hear about certifications, but you want a good one. Great, let’s talk about some!

Which next? Well, let’s hit one of the odd-ball specialty certifications by Microsoft. The test is 070-0158. Sounds really engaging doesn’t it? Microsoft test 070-0158 or even 70-158 as some people will write it. OK, no, the test number just sounds lame… but what does it get you? How about adding “Microsoft Certified Technology Specialist (MCTS): Forefront Identity Manager 2010, Configuration” to you resume? Um, er, what does that mean? I mean seriously, does anyone care or understand? And is it a title or what?

So first let’s talk about what an MCTS is. Microsoft Certified Technology Specialist (MCTS) certifications are designed to validate candidates’ skills at using, planning, deploying and troubleshooting a specific Microsoft technology. They are also sometimes also used as stepping blocks for the Microsoft Certified IT Professional (MCITP) or Microsoft Certified Professional Developer (MCPD) certification. With an MCITP or MCTS, it is generally considered to add the MCTS to the end of your name when emailing or signing things electronically. Such as Joe Black, MCTS. Often you can list specifics in email signatures afterwards… but in general I don’t.

Now let’s get back to the certification at hand: “Microsoft Certified Technology Specialist (MCTS): Forefront Identity Manager 2010, Configuration”. What is this one? This is a certification for the product listed, Forefront Identity Manager 2010. And as such this is an exotic one for people who deal with making Active Directory talk to other LDAP based services utilizing FIM. So the next question is: who is this for? What does Microsoft say?

“Typical candidates for this exam are Identity Specialists who deploy and manage Forefront Identity Manager (FIM) 2010 in an enterprise environment consisting of more than 5,000 identities with a dynamic lifecycle. These organizations may be geographically and/or organizationally dispersed and may require compliance with extensive regulations. The environment may include multiple applications that consume identities and/or multiple disconnected data sources.”

Don’t you love how Microsoft even has to put in parentheses what the acronyms’ are? However, more to the point… it really does say what this cert says you can do. What it doesn’t say is how good you have to be to pass the cert and if the cert is worth anything. In general with an MCTS the level of proficiency is based in more than a year of actual use of the product with heavy troubleshooting skills. So what this means is that you really know how to implement, troubleshoot… and even explain a product. Oddly this last one is almost as important as implementation skills on this one. FIM is just not a heavily used product. It is however an extremely valuable product because it makes other applications and even environments communicate by translating in a metaverse (yep, real term).

So how does this stand up to other certifications? An MCTS has a low time in use requirement; however it also is very specialized. What makes this one different is that it is on an obscure technology that is normally used by people with over ten years in the industry. So while a low level certification, this actually signifies something that normally sits with and above even an Enterprise Administrator’s MCITP. So on a ten scale, with MCM, MCSM, CCIE and JNCIE at the top as a ten, and Microsoft Technology Associate (MTA), Configuration and CCENT at the low end as a 1, how would I rate it? Alone I would rate it a 5. It connected to MCITP: Enterprise Administrator, I rate it a 7. It is a major name and brings out a lot of conversation. It is also shows significant skills and determination, as well as longevity in the field.

One caveat as always: remember when discussing certs. Certs do not equal experience. Certs validate experience.

What do you think? And what certification would you like me to take a look at and grade next week?

Have you ever backed up your Domain Name System (DNS) records independent of the traditional system state backup of your domain controllers? No? So, if you lose DNS you are doing a full Active Directory restore? Yep. Oh, OK.

Um, why? Isn’t that kind of extreme? Let’s make this a little simpler, OK?

As Active Directory is one hundred percent dependent on the Domain Name System (DNS), it is critical that you back up your DNS servers on a regular basis. The most common method is to do a system state backup. Although this technique does work, it is all-or-nothing. This means that if you are having DNS problems, what do you do? You restore the system state which includes the Registry, Active Directory database, etc. Additionally, there is not a file to review in case one IP and name combination is lost. It is simply all or nothing.

How about a better way for those times when you don’t want to blow up the current domain?

Backing up an Active Directory integrated zone is just a little more complicated that the tradition DNS backup. It is simple. Do it. It is worth it. Really.

How? These simple steps. Export the zone and backup the export file. Yep, that is it. Use the command following to do it.

dnscmd /ZoneExport FQDN_of_zonename backup\Zone_export_file

dnscmd /ZoneExport AD.lab backup\AD.lab.dns.bak

dnscmd WS12-DC01 /ZoneExport AD.lab backup\AD.lab.dns.bak

The first line is the syntax. The next command will export the zone for AD.lab on the local server to a file called AD.lab.dns.bak in the %SystemRoot%\System32\Dns\Backup folder. The second command exports the same zone from the DNS server WS12-DC01 to a file named AD.lab.dns.bak in the %SystemRoot%\System32\Dns\Backup folder on the server named WS12-DC01. Be aware though that the backup command will not over-write any previous backup of the same name.

Oh, you want to know how to restore? Well, it will restore you whole DNS for that zone so be careful. Traditionally you do this after the zone is gone. Check the tech tip for the steps for a basic restore.

Well, first off validate that you have a current system state backup and a backup of the zone. The system state is in case of corruption. Remember, your backup procedures should include testing any processes in the lab before doing so in live production. Now delete the current corrupt zone. Now restore the zone.

The first command loads the zone as a primary zone. The second converts the zone to Active Directory integrated DNS. The last enables secure updates. Oh, and you are now done. If you had specialized security… time to rebuild that as well. if you need it.

Hard? Nope. How about you backup the DNS in your domain now? It just takes a minute to export it. So let’s export and backup your DNS. One more step to towards working towards the new modeus operendi: just say no to “blowing up” your Active Directory.

Do you have a lab? Specifically, do you have an Active Directory lab? Do you need a lab? Hint: the answer is yes. The modus operandi for the industry has been simple: salvage your old equipment and build an ad hoc lab. Times have changed and that now begs the question: is that really good enough? Nope. It wasn’t back in the day, and it certainly isn’t today.

So let’s get down to business and look at what you need for your lab. One thing any IT professional will agree is that building a lab is an essential part of preparing for a variety of tasks such as an Active Directory transition, an Active Directory migration, Novell Migration, schema changes and the list goes on. Anything that changes your current settings in Active Directory beyond a single account should always hit the lab first. The lab is there so you can do a dry run, practice and validate any process. It is a lab environment. If it blows up, you get the experience gained from rebuilding it.

So a lab should closely mirror the production environment (in every way that is feasible). While it is not feasible to completely mirror production’s many application servers and enterprise computing platforms, it should be as close as possible and account for the business critical applications, at least include a small sampling of those servers. It should also have workstations if you use workstations.

Without a close replica of the production environment organizations cannot successfully plan for potential show stopping events from infrastructure changes. Think of the results from a schema extension preventing a domain upgrade (I have seen these). Think of a time configuration error that is allowing domain controllers to lose synchronization (these are common). Think of a large PowerShell script import of thousands of groups being imported to the wrong OU (stopped this before).

Any process that has an impact on your current Active Directory environment should be tested.

An implementation of a new lab cannot account for the “history” or breadth of the production environment. This includes some of the following examples: schema extensions over time, upgrades of operating systems, administrative changes in functionality, and current policies in effect, and anything you don’t see in a DCDIAG. Everyone agrees that implementing a lab environment using the concept of “mirroring”, or as close to a mirrored environment as possible is crucial to a successful implementation of an upgraded or migrated environment.

There are many strategies for implementing a lab environment but they all have their own caveats to plan for in order to avoid disaster. The best mirror methodology is to introduce a new domain controller in a production domain, replicate all data, remove the domain controller and place it in the lab environment, and then perform metadata cleanup on both the production and lab environments. This gets you a copy of the real environment. In the production environment the metadata cleanup would remove existence the newly promoted DC to avoid replication failures. In the lab environment the metadata cleanup would involve removing all existence of the missing domain controller in the forest. The cleanup consist of seizing FSMO roles, NTDSUTIL being used to clean up the metadata and then going through and manually pruning each side from the other.

There is a major risk for this best of breed lab. The lab environment must be guaranteed to never touch the production environment. If this were to occur, two separate domain controllers would attempt to assume the FSMO roles and would cause all sorts of issues… think best possibility would be USN rollback and dire replication issues. As such, while a lab environment is essential, there are many preventative tasks that must be performed to ensure the lab environment never is in contact with the production environment. This should be locked down by all available security measures. A very critical security concern is if the lab environment is a virtualized environment. Domain controllers are only as secure as the server in which they run on.

I always recommend using a dedicated Hyper-V V3, VMware vCenter Lab Manager or VMware ESXi environment. Please note that this security is essential, as if a VHD or VMDK files end up in production they can potentially cause a true full scale outages and additionally security risks.

Scared yet? Should be. Well this best of breed, is the best of breed but it needs to be done methodically.

Going to give it a try? Good!

Now everyone, let’s work together to make the new IT modeus operendi: just say no to “blowing up” your Active Directory.

When you start building domain controllers, one of the simple ideas people bring up is that you always leave the Active Directory data (NTDS database, Sysvol and logs; also known as directory data) where the default in the windows directory. The idea is they are tucked away and difficult to stumble across accidentally and start playing around with them. Others simply say: it is where they belong.

Well, it is probably obvious by now, that I disagree with the popular sentiment.

One of the problems is that most people confuse the Active Directory Domain Services role (making the server a Domain Controller) with the server. The reality is that the Active Directory Domain Services role is simply that: a role. It is a role that when doing work in your lab, or troubleshooting and restoring your enterprise systems you need to be able to easily backup or even copy everything related to Active Directory. Why hide it in the Windows directory with thousands of other files and folders?

When you isolate these folders and files into a single root level directory (I like C:\ADDS) you gain one directory to manage. So it is one directory to manage. One directory to isolate from antivirus; yes, you have to avoid the NTDS Database, Sysvol and Logs from anti-virus scanning (if you even put anti-virus on your domain controllers… another topic to discuss at a later date). It also allows you to easily copy everything to do with Active Directory with the right click of a mouse or a simple backup command (to get everything). This is awesome when troubleshooting things like Journal Wrap or doing restoration of login scripts or even Active Directory itself. It is a life saver for a quick directory restore operation.

The idea here is to make your management of Active Directory simpler. Now comes some neat things you can do if you have additional physical volumes to move these files to.

In a large environment, placing the directory data (Sysvol, NTDS, Logs) on its own NTFS partition reduces disk I/O. This can reduce some chances of error, such as FRS just not keeping up with changes. Additionally, reducing disk I/O allows the Active Directory Domain Services server more efficiently as well. This can be vital for an enterprise PDC Emulator. More efficient, better I/O adds to the number of client requests that can be processed. From a performance point of view you could use three separate disk arrays. One disk array for your boot partition, one disk array for your Active Directory database and the Shared System Volume (SYSVOL) folder and one disk array for your Active Directory log files.

However remember, Active Directory is based on a database. As such, if you want the absolute best performance possible… separate all three parts of the directory data onto three separate drives. Granted, this is only done when an enterprise needs extreme responsiveness. However, this starts to get to be a management headache, as you now have to backup three separate drives. Lets just keep it simple if we can, ok?

What are the negatives? If this is going to be a Domain Controller that is not going to be managed by trained staff… don’t do this. Some administrators won’t realize that they should look for the directory data. However, this is a situation where training can fix this. Additionally, sometimes you may want to use simple step by steps found online… and will need the administrator to adjust the commands on the fly.

Is it doable with the negatives? Yes. Do I consider the advantages more valuable than the risks from the negatives? Absolutely. It keeps things simple for backups, restores and troubleshooting. You can isolate your directory data and make your life simpler.

Have you ever just been starring at your computer saying, “Come on already!” Or, “if you don’t hurry up, I am getting out a soldering iron and converting you into a toaster!” No? Are you lying to me? Am I just impatient? Well, if I am, I am not alone. However, experience has been kind enough (read: I am still alive) to teach me that sometimes, it just takes time.

In general, patience is hard learned in computer work. I remember coming up with the Starbucks rule. When creating VPN changes, make your changes and then go to Starbucks; when you get back it will be working. When it comes to Active Directory, it is actually worse. Patience isn’t needed just to get the things working: patience is required so that Active Directory isn’t damaged by troubleshooting.

You see, when doing Active Directory work, you sometimes need to slow down. Why? It all takes time. KCC, time synchronization and replication over however many links data has to go across. This is just how Active Directory works since it is a multi-master system. And before anyone gets any ideas… yes, we all want it to be a multi-master system and accept this as normal.

As a general rule, when doing a major Active Directory project, work at the pace of the slowest task. Let the changes matriculate. They need to. In fact, over time it appears that once everything is done and complete… give it a good twenty four hours and then double check it.

Twenty four hours? Am I insane? Nope.

Take the time and validate that the changes matriculated. Why? You see one of the biggest pains in Active Directory is when you don’t realize your environment has some KCC, replication or time errors… and the changes you think went through… didn’t. This does happen. So don’t rush it.

When you rush it, you make mistakes. Like not backing up every domain controller when doing a domain transitions or not documenting the changes you are making in a migration. Take the time that the job actually requires.

Oh, and since you’re now taking the time to do it right, how about we all try and remember to finish the job. Active Directory projects are left incomplete with epic proportions. Take the time, and finish it. Really finish it. Yes, even fill out sites and services. It is all important and makes it easier for those who come after you.

When working with Active Directory just take it methodically. Then make sure the replication is done. Rush and you may make a mistake and end up rebuilding your forest.

Sometimes you just want to see how something is done. Well today, we are going to look at how to build a basic forest. This is for the first domain controller in your lab. Yes, I said lab. You want a lab. Why do you want a lab? This lets us see if anything is going to break? Or as close as we can ever get.

Now everyone, let’s work together to make the new IT modeus operendi: just say no to “blowing up” your Active Directory.

So, in sixty seven simple steps… let’s build the lab so we can make that new modeus operendi. Just follow the recorded steps.

The release of WS12 is going to have a major impact on all of us who implement and manage Windows environments. There are major changes and we are all going to learn them or go the way of the dinosaur. As someone who grew up in CP/M, trust me: it can be done. So what are the big standouts on changes that I am going to have to worry about?

First off we have the interface, and for the first time since Windows NT 4, we have a major interface overhaul. And I mean a major overhaul. To me it seems like an amalgamation of Windows 2000, 3.0 (yes, 3.0) and Windows Phone 7. Does it work? Yes. Do I consider the look somewhat hideous? Yes. Could I get used to it? You bet.

PowerShell V3 for the win. When you add domain functionality you get a link that lets you output the settings. These are actually an output of a PowerShell script. PowerShell is now everywhere… as it should be. The days of DOS, PowerShell V1, PowerShell V2, Quest PowerShell and VBS being mixed everywhere is done. When servers are 2012, PowerShell V3 rules the roost and renders the others inconsequential. Now, if you are a VBS guy, well, as a CLI guy, I feel for you… but get over it.

While I am going to skip talking about all the incredible new features of 2012, let me just set one expectation: Active Directory Domain Serveries 2012 is a massive upgrade. Not a minor update like 2008 R2, where you received great functionality with hideous management so people just ignored it. No, you gain everything. Features, functionality and most of all usability; Server 2012 has it all in the new version of Active Directory. Think of all the pain we have all gone through trying to convert from Quest PowerShell to PowerShell V2 AD Cmdlts? Well everything you do now is shown with its PowerShell syntax.

I really want to go over the new functionality like the new virtualization safe domain controller cloning or the death of the USN rollback… but let’s not get ahead of ourselves. Download the OS and install it. It took me 30 minutes to download, install and configure Active Directory. How long do you want to wait to lab yours?