How to Drive Revenue with Active Directory Health-Checks

How to Drive Revenue with Active Directory Health-Checks

As an IT service provider, you are always looking for new ways to generate additional revenue. One fantastic way to add to your monthly bottom line is to offer free or low-cost services to your clients, which then lead to lucrative paid engagements and contracts. This strategy is no secret.

One way to implement this strategy is to offer free Active Directory health checks to your customers. Because so much relies on Active Directory, it is a vital component to almost any business enterprise - large and small. In fact, Active Directory is so critical that problems with it can actually bring production to a grinding halt.

Knowing this, you should be making every effort to get your foot in the door with clients by offering free AD health-checks. Why? They are easy to perform, they do not require much time to complete, and they quite often lead to well-paying remediation projects.

Why Active Directory?

Almost every business process relies on active directory in some way. Whether it is a service account that runs a process or a user account that needs to login, AD is responsible for the authentication of these accounts.  If a service account cannot authenticate, the business process fails.  If a user cannot login, the user cannot access the business application to perform his or her job.  In both instances, the business falters.

Other impacts that an unhealthy active directory can have on a business include the inability to access file shares and printers.  Even network access and VPN access can be impeded.  Employees are none too happy when active directory problems prevent finance from running the payroll process.  Vendors are not very interested in hearing about AD problems when they are waiting on the business to pay an invoice.

Minor or major, problems associated with an unhealthy active directory will have negative impacts on any business. As such, it is a prime target for IT service providers who are looking for low hanging fruit or "easy wins".

Things to Look For

As complex as active directory is, countless issues can crop up - especially in environment where AD is not regularly maintained or monitored. Common issues to look out for in any active directory environment include DNS issues, time sync issues, replication problems, group policy issues, and orphaned objects. It is not a huge list by any means but a problem in any one of those areas is likely to affect the business in a negative manner. While some problems might be more subtle than others, some problems can bring business to a complete halt.  Fortunately, most issues can be identified in a routine health check before they become larger catastrophes.

The point of offering a free health check of active directory IS NOT to spend 8 hours doing a deep dive of the environment. The goal is to perform a cursory review of some basic functionality of AD, using a handful of tools to identify anything out of the ordinary. When performed correctly, a decent cursory-level health check of active directory should take no longer than 60-90 minutes, depending on the size of the ad environment. However, a properly performed cursory-level heath check is generally sufficient to uncover most common issues within the environment - common issues that you can then remediate during a paid remediation project.

When performing a heath check, you are going to want to pay special attention to six key areas:

Time Sync

If time sync is off within the AD forest, it is going to inevitably cause Kerberos issues. Since AD relies on Kerberos for authentication, out-of-sync clocks on servers and workstations is going to ultimately prevent account logons.  This will cause services to stop running, prevent users from logging in, and serves/workstations from authenticating.  Things can quickly get out of hand, if time sync is not working properly or if it is misconfigured (very common).

Replication

Active directory is effectively a distributed database / identity management system that is replicated across all domain controllers in the environment. Any one of thousands of issues can cause replication issues. Issues with AD replication will result in an inconsistent active directory, meaning new users and other objects will not be visible in parts of the network.  Conversely, deleted objects will remain visible.

Event Logs

Event logs are the first step in the troubleshooting process. During a health check, you will want to see what the event logs look like on the domain controllers.  Event IDs noted in the events themselves will often indicate, with good accuracy, what is going on in AD.

DC Diagnostics

Domain controllers need to be able to talk to one another and they need to be able to resolve records in DNS properly. Performing DC diagnostics will often uncover underlying resolution issues, authentication issues, and even some replication issues.

Group Policy

Businesses use Group Policy to control the configuration of the environment. Printer mappings, file share mappings, and even Wi-Fi connections are all controlled via group policy - and that is just the tip of the iceberg. When issues arise with group policy access or replication, user experience is negatively impacted.

Orphaned Objects

A poorly maintained active directory can very easily become cluttered with objects that no longer exist. While this isn't technically terrible when it comes to workstations and users (although a security risk), things do start breaking down in active directory when domain controllers and servers are improperly decommissioned and left orphaned in AD. As scary as it sounds, this particular issue is usually the most common of those listed.

Performing a free ad health check does not have to be difficult nor time consuming. However, the finished report must provide at least a good overview of key pieces of ad and what issues have been uncovered.

Document the Environment

Begin the health check by running the AD Topology Diagrammer tool. To do this, you will need to download it here and have Visio installed on your computer. In addition, you will need an active directory account to access the AD you are investigating. Running the diagrammer tool will produce a Visio diagram of the entire active directory.  You can work from this diagram while performing your health check.  The diagram is also a nice “bonus” document to provide the customer as I have found most companies DO NOT have an updated diagram of the current AD infrastructure.

Make sure the servers depicted in the generated document match those that actually exist.

Review Time Sync

In a properly configured AD environment, the only computer getting its time from an external source is the domain controller that is serving as the PDC emulator. All other domain controllers should be getting their time from the PDC emulator. Member servers and workstations, in turn, should synchronize their time from the closest domain controller. This hierarchy ensures that all machines in the active directory have synchronized times.

To confirm the time sync configuration on domain controllers, servers, and workstations, run the following command from a command prompt on each machine:

W32tm /query /configuration

While you SHOULD run the command above on all domain controllers, it is not always practical to run it on all servers and workstations. Instead, since this is a free cursory-level check, run the command on a few servers to spot-check.  Do the same for workstations if you have access to them.

The only machine that should show a “type” of NTP is the PDC emulator.  All other machines should show NT5DS as the time sync type.  A time sync type of NTP indicates the machine is relying on a manually configured time source.  A type of NT5DS indicates the machine is relying on active directory hierarchy for time sync.

If any machine other than the PDC emulator shows NTP, note this as an exception in your final report.

Review Replication Results

There are two types of replication that you need to check: SYSVOL Replication and AD Replication. Since items such as group policy, login scripts, and such are stored in SYSVOL, you need to make sure it is replicating properly. User objects, computers, and such are stored in the AD database itself so that replication also needs to be checked.

To check replication of SYSVOL, simply create an empty text file and copy it to the SYSVOL folder on one domain controller (\\servername\sysvol).  After this has been done, confirm that the text file shows up in the SYSVOL folder on all other domain controllers as well.  If it does not, make a note of it as an exception.

Testing replication of AD is a little more complicated – but not much.  To ensure every DC is replicating with every other DC in the environment, run the follow commands to check replication on every DC:

repadmin /showrepl server1.microsoft.com

repadmin /replsummary server1.microsoft.com

The command above will display a replication summary for each domain controller and show any replication failures that have been detected. Document your findings, highlighting any failures discovered.

Review the Event Logs on Domain Controllers

As part of any active directory health check, make sure you review the Domain Services / Active Directory event logs on each domain controller for any Warning or Error events, taking care to note the Event IDs of any events that are found. It is not critical to get into details of each one yet, since this is just a health-check and not a remediation project.  Just be sure to document what you found and note that each event indicates a potential AD problem.

Perform Domain Controller Diagnostics

The DCDIAG tool is an extremely easy tool to use. Simply open a command prompt on a domain controller, type DCDIAG, and press ENTER. The tool will perform a battery of diagnostics against the domain controller that it is running on and spit out a report of what it found. Generally speaking, it is very easy to identify problems in the output because DCDIAG will typically show PASSED or FAILED for each test it performs.

Run DCDIAG on every domain controller and document any issues it finds.

Confirm Group Policies are Accessible

Because group policies control AD security and user environments, it is important to confirm that all product group policies are working and accessible.

The easiest way to ensure the policies are accessible is to login to a domain controller, launch the Group Policy Management Console, and right-click each policy to view its properties.  If any policy generates and access error (or any other error) when trying to view its properties, note it as an exception.

Check for Orphaned Domain Controllers

In an ideal environment, there would be ZERO orphaned users, workstations, or servers in active directory.  However, in reality, you will almost always find orphaned objects in AD.  That said, what you really want to be concerned about are orphaned domain controllers – since these will cause DNS problems as well as replication failures in AD.

To check for orphaned domain controllers, do the following:

• Login to a domain controller and launch the AD Sites and Services application
• Expand the servers folder on the left until all servers are exposed
• Ensure that there is an NTDS Settings leaf under each server
• Note each server that does not have an NTDS Settings leaf under it

After you have checked for orphaned DC in sites and services, launch the DNS Management console, right-click the active directory domain on the left and select “name servers”.  Make sure that the only name servers listed are those that still actually exist. If you find servers listed that do not actually exist anymore, make a note of this as an exception.

Produce and Deliver the Final Report

When you have completed running all of your tests as indicated above, document your findings in a single report that you can provide to your customer.  My personal suggestion is to not only include the exceptions/issues identified but also include the “positives”.  If you dump the results of your diagnostic commands to a txt file when you run them, you can simply copy and paste those results into your final report or include them as an addendum to your report.  Either way works.

Use whatever report template you normally use - just make sure it looks professional.

Leverage the Fear Factor

Remember, you undertook this health-check in an effort to produce a paid remediation engagement. Sugarcoating any discovered anomalies does not really help with “selling” the paid remediation project. While I am not suggesting you overstate anything, make sure that you make it clear to your customer that failing to immediately remediate the discovered issues can lead to more significant problems down the road.  Your customer obviously cares at least a little bit about how things are running because he/she would not have accepted the health check in the first place if there were no concerns about the environment.

You ultimately want to install some level of fear in your customer that things can go badly if you are not engaged to remediate the issues identified.

Outsourcing the Whole Project

The purpose of this guide was to provide an outline of how to perform a high-level active directory health check, how to identify common issues, and how to present the results in a way that results in a paid remediation engagement. However, the health-check is the easy piece.  Remediation can become quite complex and should be undertaken only by a qualified Active Directory specialist.

If you do not have a qualified Active Directory specialist on staff, consider outsourcing the entire project to one you trust. As a senior-level Active Directory expert, I am always available for engagements if you need assistance.

Have Questions?

Need more information or clarification? Drop me a line. My contact info is home my homepage. You are also invited to attend one of my upcoming FREE webinars. Click here to register for one of them today.