Configuring IIS To Host an FTP Site (Part 2)

Some differences in the two versions of the FTP services that can be run on Windows Server 2008.

Introduction
In my previous article in this series, I showed you how to install the FTP role services, and I began talking about SSL encryption for FTP. Although SSL encryption is certainly not a requirement for using FTP, it is a good idea to at least give your users the option of encrypting their FTP sessions, because you never know when they will need to transfer a sensitive document. Over the next two articles, I will show you how to add SSL security to your FTP server.
The New Version
If you look at your server’s Administrative Tools menu, you will notice that it contains a link for the Internet Information Services (IIS) Manager, and another link for the Internet Information Services (IIS) 6.0 Manager, as shown in Figure A. There is actually a really good reason for this.

Figure A: Windows Server 2008 includes two separate IIS management tools

When Microsoft created Windows Server 2008, one of their goals was to completely revamp the FTP server in an effort to modernize it. However, the new code was not completed in time for the Windows Server 2008 release. Since Microsoft did not want to release Windows Server 2008 with no FTP support, they ended up porting the IIS 6.0 version of the FTP services from Windows Server 2003 into Windows Server 2008.
If you choose the Internet Information Services (IIS) 6.0 option from the Administrative Tools menu, you will see the console shown in Figure B. This is essentially just a watered down version of the IIS Management Console that was included for the sole purpose of managing the FTP services. If you right click on the Default FTP Site, and choose the Properties command from the resulting shortcut menu, Windows will display the FTP site’s properties sheet. A quick look at the properties sheet’s various tabs will show you that there simply isn’t an option for encrypting FTP sessions.

Figure B: The Internet Information Services (IIS) 6.0 manager is a leftover from Windows Server 2003
The good news is that you are not stuck using the legacy FTP server. Microsoft went on to complete their new FTP server, and released it as an out of band add-on. This means that it is not technically a part of the operating system, but is an add-on that is designed to work with the operating system.
I once asked someone in Redmond if the new version of the FTP server would be integrated into Windows Server 2008 when the next service pack was released. I was told that the FTP server was going to remain an out of band add-on, because doing so allowed the IIS team to modify it whenever they wanted without having to deal with all of the politics associated with modifying an operating system component.
Since the new FTP server is far superior to the one that ships with the operating system, let us go ahead and uninstall the IIS 6.0 version, and then we will download and install the new version.
Removing the IIS 6.0 FTP Server
Even though we just installed the IIS 6.0 version of the FTP services, let us go ahead and remove it. I only wanted to install it as a way of showing you the difference between what was included in Windows Server 2008, and what you got with the out of band release.
To remove the previous version of the FTP services, open the Server Manager, and select the Roles container from the console tree. Scroll down until the console lists all of the role services that are installed, and click the Remove Role Services link. When you do, Windows will open the Remove Role Services Wizard. Deselect the FTP Publishing Service check box, and click Next, followed by Remove and Close.
Installing the IIS 7 FTP Server
The first thing that you will have to do is to download the Microsoft FTP Services for IIS 7.0. The actual download link that you will use varies depending on whether you are running the 32-bit or the 64-bit version of Windows Server 2008. If you are running the 32-bit version, you can download the FTP services here. If you are running the 64-bit version of Windows Server 2008, then you will want to download the FTP services here.
Save the file that you have downloaded to an empty folder on your server’s hard drive. Next, double click on the file that you have downloaded, and click the Run button when prompted by Windows. Windows will now launch the Microsoft FTP Services for IIS 7.0 installation wizard.
Click Next to bypass the wizard’s Welcome screen. The wizard will now display the End User License Agreement. Accept the license agreement, and click Next. At this point, you will see a screen that is similar to the one shown in Figure C, asking you which of the individual FTP services components you would like to install. For our purposes, make sure that all of the components are set to be installed, and click Next.

Figure C: Make sure that all of the FTP components are going to be installed
You should now see a message telling you that Windows is ready to install the FTP services. Click the Install button to initiate the installation process. When the installation process completes, click Finish.
Accessing the FTP Server
Now that our quick and painless installation process is complete, let us open the IIS 7.0 management console. To do so, select the Internet Information Services (IIS) Manager option from the Administrative Tools menu. When the Internet Information Services (IIS) Manager console opens, select the container from the console tree that bears the name of your server. As you can see in Figure D, some FTP management tools have been added to the server.

Figure D: The Internet Information Services (IIS) Manager console now supports FTP
Now scroll through the console tree to Sites. Right click on the Default Web Site container, and choose the Add FTP Site option from the shortcut menu. You will now be prompted to enter a name for the FTP site, and a physical path that you want to link the site to. Go ahead and do that, as shown in Figure E, and then click Next.

Figure E: Enter the name of the site and the site’s physical path
On the following screen, select the Allow SSL option, and click Next. Click Finish, and IIS will create a bare bones FTP site. We will configure and secure this site in Part 3.
Conclusion
As you can see, the IIS 7.0 version of the FTP services offers a lot more options than the IIS 6.0 version does. In the next article in the series, I will show you how to apply SSL encryption to an FTP server. In the mean time though, I would strongly recommend that you take the time to check for any updates to the FTP services that might have been released since the time that Microsoft first made the services available.

Configuring IIS To Host an FTP Site (Part 1)

How you can configure IIS to act as an FTP server.

Introduction
It is easy to think of IIS as just being an application for hosting Websites, but IIS can also be configured to act as an FTP server that allows users to upload and / or download files. An IIS FTP site can be bound to a Web site or it can be a standalone site. In either case, IIS offers you a great deal of flexibility in setting up an FTP site. In this article series, I will show you how to install the necessary services, and how to provision your IIS server. I will also show you some variations of these techniques that you can use to adapt your FTP site to specific types of situations.
Why Use FTP?
FTP (File Transfer Protocol) is far from being the only game in town when it comes to file transfers, so you may be wondering why I am bothering to write about FTP as opposed to some other type of file transfer mechanism. After all, the FTP protocol has been around since 1971, and is a bit dated to say the least.
I am not going to try to tell you that FTP is the be all – end all when it comes to file transfer protocols. There are certainly file transfer methods that are more efficient. Even so, there are a couple of different reasons why I chose to write about FTP. For starters, FTP is universal. Everybody knows what FTP is, and it works on pretty much every operating system.
FTP completely masks the complexities of interacting with various operating systems and file systems. It doesn’t matter if a user is using Linux, Windows 95, Windows Vista, or something really obscure. As long as their operating system is FTP aware, they can transfer files to or from an IIS server that is running on Windows Server 2008.
The other reason why I wanted to write about FTP is because the FTP services are included with IIS. You do not have to develop or purchase any additional software. Simply install the necessary components, adjust a few configuration settings, and you are in business.
Installing an FTP Server
Windows Server 2008 gives you two different options for installing an FTP Server. One option is that you can install the FTP server through the GUI. The other option is to configure the server to operate as a server core installation. As you might have heard, server core deployments are entirely command line driven, but are arguably more secure than their GUI counterparts because fewer Windows components are installed. In the interest of reducing complexity, I am going to focus my discussion on performing a traditional, GUI based installation.
With that said, begin the process by opening the Server Manager and scrolling through the pane on the right to the Roles Summary section. Next, click the Add Roles link that’s located within this section. When you do, Windows will launch the Add Roles Wizard.
Click next to bypass the wizard’s Welcome screen, and you will be taken to the Select Server Roles screen. Select the check box corresponding to the Web Server (IIS) role, and click Next. You will now be taken to the wizard’s Select Role Services screen. This screen lists the various IIS related components that you can install. Since many of the services required by an FTP server are selected by default, go ahead and click Next to accept the default values. You will now be taken to a confirmation screen that lists the choices that you have made. Take a moment to review the components that will be installed, and then click the Install button. When the installation process completes, verify that the installation was successful, and then click the Close button.
Now, open the Server Manager and navigate through the console tree to Server Manager Roles Web Server (IIS). Upon selecting the Web Server (IIS) container, scroll through the pane on the right until you locate the Role Services section. As you examine the entries in this section, you will notice that the FTP Publishing Service and its subcomponents are not installed.
You can install these components by clicking the Add Role Service link. Upon doing so, Windows will open a dialog box that prompts you to select the role services that you want to install. Select the check box corresponding to the FTP Publishing Service. Upon doing so, the underlying FTP Server service and the FTP Management Console check boxes will also be selected. Leave these items selected.
Click Next, and Windows will display a summary screen that shows you which role services that you are about to install. Assuming that your choices appear to be correct, go ahead and click the Install button. Windows will now install the selected role services. When the installation process completes, take a moment to verify that the installation was successful, and then click the Close button. I also recommend going back to the Server Manager and taking another look at the Role Services for the Web Server (IIS) role. You should be able to verify that the FTP Publishing Service, the FTP Server, and the FTP Management Console are all installed.
Securing Your FTP Server
Now that the necessary role services are installed, it is probably a good idea to secure your FTP server. One of the primary techniques used to secure an FTP session is to encrypt the session using SSL. Keep in mind that SSL encryption is not mandatory though. In some cases uploading or downloading unencrypted files is not a big deal. For example, I downloaded a new Microsoft Word template from one of my publishers via FTP last week. The transmission wasn’t encrypted, but it really did not matter because it was just a document template. In any case, it is a good idea to at least give your users the option of encrypting the session if they want to.
SSL encryption is based on the use of digital certificates. The certificate is not just used as the basis for encryption, it also serves as a mechanism to positively identify your server. There are actually three different options available to you in regard to using a certificate. You can purchase a certificate from a commercial certificate authority, you can generate your own certificate from a Windows Server that is configured to act as an Enterprise Certificate Authority, or you can configure your FTP server to generate a self signed certificate.
When you are trying to decide which method to use, remember that the client computer has to trust the certificate that the server is using. Windows clients automatically trust certificates from the major commercial certificate providers. They will usually also automatically trust an Enterprise Certificate Authority, so long as the client machine is a domain member. A client will never automatically trust a self signed certificate.
Conclusion
As you can see, certificate trust is a major issue when it comes to providing SSL encryption. In Part 2, I will continue the discussion by showing you how to configure a client to trust an otherwise untrusted certificate. I will also show you how to enable SSL encryption for your FTP server.

How to Install Windows Server 2008 Step by Step

Installing Windows Server 2008 is pretty straightforward and is very much like installing Windows Vista, but I thought I'd list the necessary steps here for additional information. For those of you who have never installed Vista before, the entire installation process is different than it used to be in previous Microsoft operating systems, and notably much easier to perform.

Using Vista's installation routine is a major benefit, especially for a server OS. Administrators can partition the system's hard drives during setup. More importantly, they can install the necessary AHCI or RAID storage drivers from a CD/DVD or even a USB thumb drive. Thus, error-prone floppies can finally be sent to the garbage bin.

Note: Windows Server 2008 can also be installed as a Server Core installation, which is a cut-down version of Windows without the Windows Explorer GUI. Because you don’t have the Windows Explorer to provide the GUI interface that you are used to, you configure everything through the command line interface or remotely using a Microsoft Management Console (MMC). The Server Core can be used for dedicated machines with basic roles such as Domain controller/Active Directory Domain Services, DNS Server, DHCP Server, file server, print server, Windows Media Server, IIS 7 web server and Windows Server Virtualization virtual server.

To use Windows Server 2008 you need to meet the following hardware requirements:
Component &Requirement :
~~~~~~~~~~~~~~~~~~~
Processor
• Minimum: 1GHz (x86 processor) or 1.4GHz (x64 processor)• Recommended: 2GHz or fasterNote: An Intel Itanium 2 processor is required for Windows Server 2008 for Itanium-based Systems
Memory
• Minimum: 512MB RAM• Recommended: 2GB RAM or greater• Maximum (32-bit systems): 4GB (Standard) or 64GB (Enterprise and Datacenter)• Maximum (64-bit systems): 32GB (Standard) or 2TB (Enterprise, Datacenter and Itanium-based Systems)
Available Disk Space
• Minimum: 10GB• Recommended: 40GB or greaterNote: Computers with more than 16GB of RAM will require more disk space for paging, hibernation, and dump files
Drive
DVD-ROM drive
Display and Peripherals
• Super VGA (800 x 600) or higher-resolution monitor• Keyboard• Microsoft Mouse or compatible pointing device.

Follow this procedure to install Windows Server 2008:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Insert the appropriate Windows Server 2008 installation media into your DVD drive. If you don't have an installation DVD for Windows Server 2008, you can download one for free from Microsoft's Windows 2008 Server Trial website.
2. Reboot the computer.

3. When prompted for an installation language and other regional options, make your selection and press Next.

4. Next, press Install Now to begin the installation process.

5. Product activation is now also identical with that found in Windows Vista. Enter your Product ID in the next window, and if you want to automatically activate Windows the moment the installation finishes, click Next.

If you do not have the Product ID available right now, you can leave the box empty, and click Next. You will need to provide the Product ID later, after the server installation is over. Press No.

6. Because you did not provide the correct ID, the installation process cannot determine what kind of Windows Server 2008 license you own, and therefore you will be prompted to select your correct version in the next screen, assuming you are telling the truth and will provide the correct ID to prove your selection later on.

7. If you did provide the right Product ID, select the Full version of the right Windows version you're prompted, and click Next.

8. Read and accept the license terms by clicking to select the checkbox and pressing Next.

9. In the "Which type of installation do you want?" window, click the only available option – Custom (Advanced).

10. In the "Where do you want to install Windows?", if you're installing the server on a regular IDE hard disk, click to select the first disk, usually Disk 0, and click Next.

If you're installing on a hard disk that's connected to a SCSI controller, click Load Driver and insert the media provided by the controller's manufacturer.
If you're installing in a Virtual Machine environment, make sure you read the "Installing the Virtual SCSI Controller Driver for Virtual Server 2005 on Windows Server 2008"
If you must, you can also click Drive Options and manually create a partition on the destination hard disk.
11. The installation now begins, and you can go and have lunch. Copying the setup files from the DVD to the hard drive only takes about one minute. However, extracting and uncompressing the files takes a good deal longer. After 20 minutes, the operating system is installed. The exact time it takes to install server core depends upon your hardware specifications. Faster disks will perform much faster installs… Windows Server 2008 takes up approximately 10 GB of hard drive space.

The installation process will reboot your computer, so, if in step #10 you inserted a floppy disk (either real or virtual), make sure you remove it before going to lunch, as you'll find the server hanged without the ability to boot (you can bypass this by configuring the server to boot from a CD/DVD and then from the hard disk in the booting order on the server's BIOS)
12. Then the server reboots you'll be prompted with the new Windows Server 2008 type of login screen. Press CTRL+ALT+DEL to log in.

13. Click on Other User.

14. The default Administrator is blank, so just type Administrator and press Enter.

15. You will be prompted to change the user's password. You have no choice but to press Ok.

16. In the password changing dialog box, leave the default password blank (duh, read step #15…), and enter a new, complex, at-least-7-characters-long new password twice. A password like "topsecret" is not valid (it's not complex), but one like "T0pSecreT!" sure is. Make sure you remember it.

17. Someone thought it would be cool to nag you once more, so now you'll be prompted to accept the fact that the password had been changed. Press Ok.

18. Finally, the desktop appears and that's it, you're logged on and can begin working. You will be greeted by an assistant for the initial server configuration, and after performing some initial configuration tasks, you will be able to start working.
Next, for the initial configuration tasks please follow my other Windows Server 2008 articles found on the Related Windows Server 2008 Articles section below.
For Official Microsoft information on Windows Server 2008, see the Windows Server 2008 homepage.

Working With the Domain Controller Diagnostic Utility (Part 6)

Discussing the remaining tests that you can perform against your domain controllers.

Introduction

So far in this article series, I have shown you quite a few different tests that you can perform on your domain controllers by using the Domain Controller Diagnostic Utility. Even so, there are still some tests that I have not talked about yet. In this article, I want to wrap things up by showing you the remaining tests.

Register in DNS

If you have been working with Windows for a while, then I am sure that you know that the Active Directory is completely dependent on the DNS services, and that every host on your network requires a Host (A) record on the organization’s DNS server. What a lot of people do not realize though, is that when you create the first domain in a forest, there are some domain specific DNS records that are created within a folder named DomainDnsZones. This folder is located within the Forward Lookup Zones in your domain folder.

The DomainDnsZones folder mains records for each domain controller. Without these records, other servers on the network will not be able to locate the domain controller’s directory resources. It is therefore essential that each domain controller be able to register itself within the DNS. This is where the Register in DNS test comes into play. This test verifies that the domain controller is able to register a directory server locator record

You can perform the Register in DNS test by entering the following command:

DCDIAG /Test:RegisterInDns /DnsDomain:

For example, if your domain were named Contoso.com, the command would look like this:

DCDIAG /Test:RegisterInDns /DnsDomain:Contoso.com

Replications

As I am sure you know, Windows 2000 Server and every subsequent version of Windows Server use a multimaster domain model. This means that each domain controller has its own copy of the Active Directory database, and updates can be made directly to any of these copies. When an update is made to the Active Directory database, the update is then replicated to the other domain controllers.

The Replications test checks to make sure that these updates are occurring in a timely manner. If there is excessive latency in the update process, then domain controllers will remain out of sync for an extended period of time, and there is a greater potential for conflicts to occur.

You can perform the Replications test by entering the following command:

DCDIAG /TEST:Replications

RID Manager

Any time that you create a new Active Directory object, such as a user or a group, Windows assigns it a unique Security Identifier (SID). That SID is made up of a domain SID that is common for all objects within a domain, and a relative identifier (RID) that is unique within the domain. The RID master provides each domain controller within a domain a pool of RIDs that it can use when new objects are created. When the pool nears depletion, the domain controller issues a request to the RID master for additional RIDs. If the domain controller is unable to contact the RID Master, then no additional objects will be able to be created on that domain controller once the pool of RIDs has been exhausted.

The RID Manager test allows you to verify that a domain controller can identify and contact the RID Master, and that the RID Master contains the appropriate information. You can run this test by entering the following command:

DCDIAG /Test:RidManager

Services

In Windows Server 2008, the Active Directory is now listed as a service within the Service Control Manager. As you might have guessed, the Active Directory is a bit more complex than it initially appears. The Active Directory Domain Service has a number of dependency services, some of which include the DNS Server (if it is present on the server), Kerberos Key Distribution Center, Intersite Messaging, and the File Replication Service.

You can use the Services test to make sure that the Active Directory Domain Service and all of its supporting services are running. To do so, issue this command:

DCDIAG /Test:Services

System Log

According to Microsoft’s documentation, the System Log test examines the system to make sure that no errors are being generated. This makes it sound as though this test parses the System event log looking for errors. Perhaps on some level it does, but that isn’t what appears to happen when you actually perform the test.

When you run the system log test, the Domain Controller Diagnostic Utility begins by identifying the home server and the Active Directory forest. It then performs a connectivity test, a system log test (which I can only assume looks for critical events in the system log), and a series of partition tests on various Active Directory Partitions (ForestDnsZones, DomainDnsZones, Schema, Configuration, etc.)

You can run the System Log test by entering the following command:

DCDIAG /Test:SystemLog

Topology

Windows Server uses something called the Directory System Agent (DSA) to provide access to the data store. The Directory Service Agent is made up of various services and processes that facilitate that access. The DSA is a part of the Local System Authority subsystem, and is typically accessed through the LDAP protocol.

When multiple domain controllers are in use, each domain controller must have topology information that links it to other DSAs. The Topology test validates that the topology that Windows has generated is fully connected for all DSAs.

One important thing to know about the Topology test is that it is one of the few tests that is not run by default. It must be manually executed. You can perform this test by entering the following command:

DCDIAG /Test:Topology

Verify References

The Verify References test makes sure that the system references required by the File Replication Service and that the general replication infrastructure are intact. You can perform this test by entering the following command:

DCDIAG /Test:VerifyReferences

Verify Enterprise References

The Verify Enterprise References test is very similar to the Verify References test that I just discussed. Like the Verify References test, the Verify Enterprise References test checks to make sure that references required by the File Replication Service and that the general replication infrastructure are intact. What makes this command different from the Verify References command is that it checks file replication service references and the general replication infrastructure across all of the domain controllers in the entire enterprise.

This is another one of those tests that are not run by default. You can perform this test by entering the following command:

DCDIAG /Test:VerifyEnterpriseReferences

Verify Replicas

The Verify Replicas test is another test that is not run by default, and must be manually executed. The basic idea behind this test is that Windows allows you to create application directory partitions, and those partitions can be replicated to other servers. The test allows you to make sure that all of the replica servers contain the appropriate replicas. You can perform this test by entering the following command:

DCDIAG /Test:VerifyReplicas

Conclusion

As you can see, the Domain Controller Diagnostic Utility is capable of performing numerous tests. In my opinion, DCDIAG is one of the most underrated diagnostic tools that Microsoft has ever created.

Working With the Domain Controller Diagnostic Utility (Part 5)

More tests that the Domain Controller Diagnostic Utility can perform.

Introduction

I ended the previous article in this series by talking about some of the individual tests that you could run by using the Domain Controller Diagnostic Utility. Although I have talked about quite a few tests so far, there are plenty of more tests that you can perform. In this article, I want to pick up where I left off, and talk about a few more tests that the Domain Controller Diagnostic Utility can perform.

Locator Check

The Locator Check is one of the more important tests that you can perform using DCDIAG. As I am sure you probably know, the Active Directory assigns various Flexible Single Master Operations (FSMO) Roles to certain domain controllers within the forest. The global FSMO roles are initially assigned to the first domain controller in the forest. There are also some domain level FSMO roles that are assigned by default to the first domain controller in each domain.

The Locator Check test performs tests to make sure that the servers that are hosting the global FSMO roles are known, and that those servers can be located. More importantly, it checks to make sure that the servers hosting global FSMO roles are responding to requests.

Performing a locator check is simple. All you have to do is enter the following command:

DCDIAG /TEST:LocatorCheck

Of course this is just the simplest example of how you would run a locator check test. You have the option of specifying a particular domain controller and a set of authentication credentials just as you can for any other test.

The Intersite Test

Depending on your Active Directory’s topology, the Intersite test may also be an important one. When you run the Intersite test, the Domain Controller Diagnostic Utility performs a series of tests to see if there are any problems with bridgeheads that could cause Active Directory information from replicating across site boundaries.

The syntax used for running the intersite test is almost identical to the one used for the locator check. If you want to perform an intersite test, just enter this command:

DCDIAG /Test:Intersite

The KCCEvent Test

Another replication related test is the KCCEvent test. This test is used to make sure that the Knowledge Consistency Checker (KCC) is functioning, and that it is completing without producing any errors. You can run the KCCEvent test by entering the following command:

DCDIAG /Test:KCCEvent

The KnowsofRoleHolders Test

The Knows of Role Holders test checks to see if the Directory Service Agent knows which servers are hosting the various Flexible Single Operations Master Roles. If you just want to run a quick test, then you can do so by entering this command:

DCDIAG /Test:KnowsOfRoleHolders

Although that test will usually get the job done, you may sometimes want to actually want to check to see which domain controllers that the Directory Service Agent thinks are holding the roles. If you want to identify the individual servers, then you will need to run this rest in verbose mode. To do so, enter this command:

DCDIAG /Test:KnowsofRoleHolders /v

The Machine Account Test

In an Active Directory environment, servers and workstations are joined to a domain. This process of joining a machine to a domain causes a machine account to be created. Like a user account, a machine account has a corresponding password and a number of other attributes that are designed to identify the individual machine. If the machine account becomes corrupted or falls out of sync with the Active Directory, then the corresponding machine will not be able to connect to the domain. Fortunately, there is a test that you can use to check the integrity of a domain controller’s machine account. You can perform this test by entering the following command:

DCDIAG /Test:MachineAccount

In all of the years that the Active Directory has been around, I have only run into a few situations in which a problem with a machine account kept a machine from functioning correctly. In most of those cases, the problem was caused by the machine account’s password getting out of synch with the password for the machine account that is stored in the Active Directory database.

If a machine account does have problems though, there are a couple of optional switches that you can use to correct the issue. One such switch is the /FixMachineAccount switch, which resets the accounts various flags. If that does not correct the problem, then you can always try recreating the machine account by using the /RecreateMachineAccount switch.

The Naming Context Security Descriptors Test

One of the more obscure tests is a check to see if the security descriptors on the naming contexts are correct. If the security descriptors are invalid, then replication may fail. You can run this test by entering the following command:

DCDIAG /Test:NCSecDesc

NetLogons

A similar test related to replication is the NetLogons test. It checks to see that replication is not failing because of insufficient logon privileges. You can run this test by entering the following command:

DCDIAG /Test:NetLogons

The Objects Replicated Test

Another important test related to the replication process is the Objects Replicated test. This test is primarily used to confirm that machine accounts have replicated across all of your domain controllers, but it can also be used to check to see if other types of objects have replicated as well.

In order to use this test, you are going to have to know the distinguished name (DN) of the object that you want to test. If the object that you are looking up is something other than a machine account, then you will also have to know the object’s naming context. The syntax for this test looks something like this:

DCDiag /Test:ObjectsReplicated /ObjectDN: /N:

The Outbound Secure Channels Test

As the machines that store user passwords and various other security settings, domain controllers are some of the most sensitive servers on a network. As such, Microsoft has configured the domain controllers to communicate with each other over a secure channel whenever possible. This prevents people from using a packet sniffer to steal Active Directory information as it replicates from one domain controller to another.

By definition, a secure channel is an authenticated remote procedure call (RPC) connection between two machines in a domain with an established security context used for signing and encrypting RPC packets.

It should therefore come as no surprise that the Domain Controller Diagnostic Utility provides a test for checking outbound secure channels. This is one of those tests that is not run by default, so you will have to run it manually if you want to use it. The syntax looks like this:

DCDIAG /Test:OutboundSecureChannels /TestDomain:

Normally, this test will only check the domain controllers within the current site. You can force the test to check external sites by adding the /NoRestriction switch to the test.

Conclusion

In this article, I have talked about several of the tests that you can perform against your domain controllers by using the Domain Controller Diagnostic Utility. Believe it or not, we are not done yet. There are still several more tests that I want to talk about. In the next article in the series, I will wrap things up by talking about the remaining tests.

Working With the Domain Controller Diagnostic Utility (Part 4)

Demonstrating some additional tests that Domain Controller Diagnostic Utility can perform.

I ended the previous article in this series by talking about some of the individual tests that you could run by using the Domain Controller Diagnostic Utility. In this article, I want to pick up where I left off and talk about more tests that you may perform.

DCPROMO

Some of the tests that are available through the Domain Controller Diagnostic Utility tend to be a bit obscure to say the least. In contrast though, the DCPROMO test is actually very useful. It is designed to let you test a server’s readiness prior to promoting the server to a domain controller. Granted, promoting a server to a domain controller is a fairly simple process. You just enter the DCPROMO command, click Next a few times, and you are on your way. Even so, I have created hundreds of domain controllers over the years, and it has been my experience that every once in a while the process goes belly up because of something unexpected. Personally, I would rather know up front whether or not the server was prepared to be promoted to a domain controller, then to try the promotion, have something go wrong, and have to figure out why. Of course if the domain controller promotion process does end badly, then you can always use the DCPROMO test after the fact to help you to figure out what happened.

If you are going to use the DCPROMO test, then you are going to have to use at least two command line switches with it. The first switch that you have to use is the /DNSDomain switch. You must use this switch to tell the Domain Controller Diagnostic Utility which domain the server is going to be made a domain controller in.

You have to follow the /DNSDomain switch with a secondary switch that tells the Domain Controller Diagnostic Utility what your intentions are for the server. For example, if the server is going to be a domain controller in a new forest, then it would need to be tested differently than it would if it were going to be an extra domain controller in an existing domain.

The switches that you use to tell the Domain Controller Diagnostic Utility how the new domain controller will fit into the existing Active Directory structure are self explanatory for the most part. The switches are:

/NewForest
/NewTree
/ChildDomain
/ReplicaDC

For example, if you wanted to use the server as an extra domain controller in an existing domain named Contoso.com, then the command’s full syntax would be:

DCDIAG /test:DCPROMO /DNSDomain:Contoso /ReplicaDC

One caveat that I do want to mention is that if you use the /NewTree switch, then you will have to use a third switch named /ForestRoot. Simply follow the /ForestRoot switch with a colon and the name of your root domain (/ForestRoot:Contoso.com)

DNS

It is easy to think of the Domain Controller Diagnostic Utility as a mechanism for running diagnostic tests against your domain controllers. Even so, this utility comes with a whole series of tests designed to help you to diagnose problems with your DNS servers. This should really come as no surprise. After all, the Active Directory is completely dependent on the Domain Name Services, and the first domain controller in a forest is usually configured to act as a DNS server.

The DNS test is actually made up of quite a few individual tests, any of which can be performed individually. If you choose to call the DNS test without specifying any additional switches, then the Domain Controller Diagnostic Utility will run all but one of the sub tests. The test that gets skipped involves resolving external domain names. I will talk more about this test in a moment. Before I do, I want to give you a list of the tests that are performed when the DNS test is run without any extra switches. Figure A shows what some of the default DNS tests look like when executed.

Test Name	Switch for performing the test manually	Description of the test
Basic diagnostic test	/DNSBasic	This is a basic diagnostic test, which is performed any time that you perform a DNS test. This test cannot be skipped, regardless of which command line switches are used.
Forwarder and root hint test	/DNSForwarders	This test checks the DNS server’s forwarders and it’s root hints.
Delegation test	/DNSDelegation	This test checks the DNS server’s delegation
Dynamic Update Test	/DNSDynamicUpdate	This test checks to see which portion of the DNS namespace the DNS server is authoritative over.
Record Registration Test	/DNSRecordRegistration	This test verifies that records can be registered on the DNS server.

Figure A

Figure B: This is what it looks like when you perform a default DNS test

Earlier, I mentioned that the only test that is not run by default when you specify that you want to test the DNS configuration is the external name resolution test. There are a few switches that you can use if you want to run the external name resolution test though.

One option is to use the /DNAAll switch. This switch tells the Domain Controller Diagnostic Utility to run all of the DNS related tests, including the external name resolution test. The full syntax of this command is:

DCDIAG /TEST:DNS /DNSAll

You also have the option of explicitly calling the external name resolution test rather than just bundling the test with every other DNS related test that the Domain Controller Diagnostic Utility can run. If you want to explicitly call the external name resolution test, then you can do so by specifying the /DNSResolveExtName switch.

In case you are wondering, the external name resolution test attempts to resolve the domain name Microsoft.com. You can however, specify a different external domain name to be resolved by adding the /DNSInternetName switch, in conjunction with the name that you want to resolve.

SysVolCheck

One of the simpler tests that the Domain Controller Diagnostic Utility can perform is the SysVolCheck. This test performs some basic tests against various Active Directory partitions including the forest DNS zones, the domain DNS zones, the schema, the configuration partition, and on the domain partitions. You can see what the SysVolCheck test looks like when executed in Figure C.

Figure C

The SysVolCheck test performs some initial connectivity tests, and then tests the various Active Directory partitions.

FrsEvent

The last test that I want to mention in this article is the FRSEvent test. In Windows FRS refers to the File Replication Service. As such, this test checks to see if the File Replication Service is experiencing any operational errors. This is important, because if the FRS is malfunctioning, then the domain controllers can become out of sync, which can cause policies not to be applied properly until the problem is fixed.

Conclusion

In this article, I have discussed a few more tests that you can run by using the Domain Controller Diagnostic Utility. In the next article in this series I will show you some more tests that you can run.

Working With the Domain Controller Diagnostic Utility (Part 3)

This article continues the series on working with the Domain Controller Diagnostic Utility by examining some of the individual tests that can be performed.

Hopefully by now, you understand that the Domain Controller Diagnostic Utility has a lot of difference which is that you can use to configure the utility to run in the way that makes the most sense for your individual situation. Now that I have gone over the command line switches, I want to turn my attention to the individual tests that the utility is capable of running.

Advertising

The first test that you can run is the advertising test. This test performs a check to find out whether or not each Directory System Agent is advertising itself. If the Directory System Agent is being advertised, then the test makes sure that the advertisement lists the domain controller as having the capabilities of a Directory System Agent.

In case you are not familiar with the concept of a Directory System Agent, a Directory System Agent (often abbreviated as DSA) is actually a collection of multiple services and processes that run on a domain controller. Its job is to provide access to Active Directory Database. The DSA is a sub component of the Local System Authority (LSA). The reason why it involves multiple processes and services is because it provides multiple mechanisms through which it can be accessed by clients.

Probably the best-known of these mechanisms is the Light Weight Directory Access Protocol, more commonly known as LDAP. LDAP is the protocol through which most of the more recent Windows operating systems query the Active Directory. Older clients still require access to the DSA, but typically do so through the Security Account Manager (SAM). These are not the only mechanism through which the DSA is accessed. For example, Microsoft exchange communicates with the DSA using MAPI-based RPC calls. DSAs also communicate with each other by using remote procedure calls.

CheckSDRefDom

This particular test verifies that all of your application directory partitions have the appropriate security descriptor referenced domains. I am guessing that this particular test is going to be meaningless for anyone who is not an Active Directory expert. Therefore, I want to take a couple minutes and explain what this test is.

As I am sure you probably know, every object in the Active Directory contains a security descriptor. The security descriptors job is to maintain a list of access control information. Normally, the built-in security descriptor works pretty well for maintaining a record of who has access to what. Problems can occur if one organization starts using application directory partitions (previously known as Active Directory Application Mode or ADAM). The reason for this is that application directory partitions are domain independent. In fact, it is possible to create an application directory partition, and then replicate that partition to other domain controllers across multiple domains. Because of this problem, Windows assigns a security descriptor reference domain to each application directory partition when it is created.

The security descriptor reference domain tells the application directory partition which domain name to use when a domain value needs to be entered into a security descriptor. Windows has lots of rules that determine what domain name is used. To put it simply, if you create a new application directory partition that is not a child of any other partition, and the security descriptor reference domain uses the forest root domain as the domain name to use within the various security descriptors. If the application directory partition is a child of another object, then it takes on the security descriptor reference domain of its parent object.

CheckSecurityError

The next test that I want to talk about is the Check Security Error test. Unlike the previous test that I talked about, the Check Security Error test is not run by default. If you want to run this test, you will have to specify it manually within the DCDIAG command.

When you run this test, DCDIAG locates any security related errors, as well as errors that may possibly be related to security, and then attempts to diagnose the problem. There is one optional parameter that you can use with this switch. The /ReplSource switch allows you to specify a particular domain controller to run the test against. You can use any domain controller that you want, regardless of its error status or of whether or not it is a current partner. Simply enter the name of the test (CheckSecurityError), and append the /ReplSource switch, a colon, and the name of the domain controller that you want to test.

Connectivity

The Connectivity test is one of the most useful tests that you can run. In fact, this test is so important that DCDIAG does not even allow you to skip it. If you run a default instance of DCDIAG, the Connectivity test is run automatically.

The connectivity test checks to see whether domain controllers are registered in the DNS. It also checks to see if it can ping each domain controller, and whether or not it can establish LDAP and RDP connectivity.

CrossRefValidation

I have to be honest and tell you that I have not been able to find a lot of documentation on this particular test. What I can tell you is that the test looks for cross references that are invalid in some manner. If you do happen to receive a cross reference validation error, the problem can often be solved by using ADSI edit to remove the offending object.

I also want to point out that if you use ADSI edit incorrectly, you can destroy your Active Directory. Therefore, I would recommend making a full, system state backup of your domain controllers prior to making any changes with ADSI edit.

CutOffServers

The last test I want to talk about in this article is the Cut off Servers test. The basic idea behind this test is that in most cases, domain controllers have one or more replication partners. If a domain controller’s replication partner is down then the domain controller may not be able to be updated with Active Directory updates, and DCDIAG will report a Cut off Servers error.

The trick to being able to solve these types of problems is that you have to be able to figure out what the replication partners were a domain controller are. The actual method varies from one version of Windows to another, but in Windows Server 2003 you can look up the replication partners through the Active Directory Site and Services console.

When the console tree opens, expand the Site container to display a list of the sites in your Active Directory. Next, double-click on the site containing the domain controller that you want to examine. Next, expand the Servers folder, followed by the folder corresponding to the name of the domain controller that you are interested in. Finally, double-click on the NTDSSettings container, and Windows will display a list of connection objects. This list displays the replication partners in the From Server column.

Conclusion

In this article, I have begun discussing some tests that you can run using DCDIAG utility. In the next part of this article series, I will continue the discussion by showing you some more tests that you can perform.

Working With the Domain Controller Diagnostic Utility (Part 2)

This article continues the series on working with the Domain Controller Diagnostic Utility by examining some additional command line switches.

n the first part of this article series, I explained that if you wanted to diagnose problems with a domain controller, you could just enter the DCDIAG command, or you could use any of the numerous available command line switches as a way of getting the utility to test the specific properties of the domain controller that you are interested in. In that article, I began showing you a few command line switches, but there are a few more switches that I want to show you. In this article, I will talk about some additional switches, and will eventually go on to talk about some individual tests that you can run.

/C

I have already mentioned that you can just enter the DCDIAG command without any command line switches, and the Domain Controller Diagnostic Utility will perform a full battery of tests against your domain controller. Even so, there are a few tests that the Domain Controller Diagnostic Utility is capable of performing, but that it does not perform by default.

If you are not really sure what is going on with your domain controller, then I recommend running the DCDIAG command with the /C switch. This tells DCDIAG that you want to perform a comprehensive set of tests. This causes the Domain Controller Diagnostic Utility to run every test that it knows how to run, aside from the DCPROMO and the RegisterInDNS tests, which I will talk more about later on.

Keep in mind that running a comprehensive set of tests can take a long time to complete. If there are tests that you know that you do not need to run, then you can use the /C switch in conjunction with the /SKIP switch. Simply append a colon and the name of the test that you want to skip to the /SKIP switch, and the specified test will be omitted from a comprehensive scan.

/F

At the beginning of Part 1, I showed you what running DCDIAG without specifying any command line switches looks like. As you may recall, the output was fairly long. Of course when I created that screen capture, I simply ran a default set of tests against a healthy domain controller. The output can be a whole lot longer if you specify additional tests, or if the tests detect problems with the specified domain controller.

In some cases, reading the test results from the screen as the tests are run may not be practical. DCDIAG may spew data faster than you can read it. This is where the /F switch comes into play. The /F switch gives you the option of writing the test results to a log file. That way, you can read the results at your leisure. More importantly you will have a permanent copy of the output that you can refer back to for reference.

To use the /F switch, simply append a colon and the path and filename of the log file that you want to create. For example, if you wanted to create a log file named TEST.LOG, then you would enter DCDIAG /F:TEST.LOG. Keep in mind that when you specify the /F switch, the output is completely redirected to the log file. This means that the test output is not written to the screen at all. For operations involving multiple tests, the server may appear to lock up while the tests are performed.

/FIX

So far all of the command line switches that I have shown you are diagnostic in nature. When you use them, they cause DCDIAG to run its tests in certain ways, but DCDIAG only reports the test results. It does not attempt to correct any problems that it may find.

If DCDIAG does report problems you can attempt to correct those problems by specifying the /FIX switch. Even though this switch is simple in that it does not require you to provide any additional attributes, there are some very important things that you need to know about using this switch.

Before you use the /FIX switch, it is important to remember what you are really doing. You are telling an automated utility to make changes to your domain controller, which often means that you are blindly modifying the Active Directory. The Domain Controller Diagnostic Utility is designed so that when you use the /FIX switch, it will only make repairs that it deems to be safe. Even so, the simple fact using this switch involves blindly making changes to a domain controller leads me to recommend that you use the switch with extreme caution. The /FIX switch is designed to be safe, but any time that you are working with something as complex as a domain controller, things can go wrong.

That being the case, I recommend that you never specify the /FIX switch the first time that you run DCDIAG. Instead, you should run your tests, and take the time to evaluate the test results before you ever use the /FIX switch. If you do decide to use the /FIX switch, then I recommend making a full, system state backup of the target domain controller before doing so.

If you want to hedge your bets a bit, then one additional precaution that you can take before you attempt to fix a domain controller is to install Windows onto a spare PC, and then configure that PC to function as a domain controller. When you are done, wait for the replication process to complete, and then shut down and unplug the PC. That way, you have a healthy domain controller that you can use to rebuild your Active Directory if something should go horribly wrong during the repair process.

/TEST

The last switch that I want to talk about is the /TEST switch. So far, most of the command line switches that I have shown you are geared toward controlling the way that the Domain Controller Diagnostic Utility behaves when running various tests. You have also seen that the Domain Controller Diagnostic Utility runs a full set of tests by default, but that you can use either the /C switch or the /SKIP switch to run additional or fewer tests respectively.

The point that I am trying to make is that so far I have worked under the assumption that you will be running multiple tests. You do not have to run multiple tests. The /TEST switch allows you to simply specify the name of an individual test that you want to run. Just append a colon and the test’s name to the /TEST switch.

Keep in mind that you cannot use the /TEST switch to run multiple tests. As you can imagine, the /TEST switch is incompatible with the /SKIP switch, since the two switches do contradictory things.

Conclusion

In this article, I have shown you some additional command line switches that you can use with the Domain Controller Diagnostic Utility. In the next article in this series, I will turn my attention to the individual tests that you can run.

Working With the Domain Controller Diagnostic Utility (Part 1)

This article explains how the Domain Controller Diagnostic Utility can be used to troubleshoot problems with the Active Directory.
Domain controllers are the backbone of just about any Windows network. After all, if your domain controllers are not working then the Active Directory does not work either. If the Active Directory does not work, then users cannot log on, group policies cannot be enforced, and a whole slew of other features become unavailable. Fortunately, Windows ships with a tool that you can use to keep your domain controllers running smoothly. This tool is called the Domain Controller Diagnostic Utility. In this article, I will show you how to use this tool to perform basic maintenance and diagnostic tasks on your domain controllers.

The Domain Controller Diagnostic Utility has been a part of Windows for quite some time now. For the purposes of this article, I will be working with the version of this utility that comes with Windows Server 2008. Most, if not all of the features that I will be talking about are also available in the Windows Server 2003 SP1 version. DCDIAG existed prior to Windows Server 2003 SP1, but many of the commands that are available today were first introduced in Windows Server 2003 SP1.

You can access the Domain Controller Diagnostic Utility by running the DCDIAG command from a Windows command prompt.

Running the Domain Controller Diagnostic

Utility.

If you want to keep things simple, you can run the Domain Controller Diagnostic Utility by entering the DCDIAG command into a Windows Command Prompt window. Upon doing so, the utility will perform a variety of tests against the domain controller that you're connected to. You can see an example of what these tests look like in Figure A.


Figure A: The Domain Controller Diagnostic Utility runs a variety of tests against a domain controller

By simply entering the DCDIAG command does get the job done, but this would not be much of an article if I just told you to run the command, and left it at that. There is a lot more to the Domain Controller Diagnostic Utility than meets the eye. Before you can really appreciate all the tool's capabilities you need to become familiar with the optional parameters that you can use in conjunction with the DCDIAG command. If you look at Figure B, you can see that the DCDIAG command’s syntax is too long to even fit on a screen capture. Like most things that are really complicated the command’s syntax is not as bad as it initially appears. Once you understand how the command works, using it becomes fairly easy.

Figure B: The DCDIAG command’s syntax is so long that it won’t even fit on the screen.

Breaking Down the Syntax

As you can see in the figure above, the DCDIAG command’s basic syntax looks like this:

dcdiag.exe /s:[:] [/u:\
/p:*||""]
[/hqv] [/n:] [/f:] [/x:XMLLog.xml]
[/skip:] [/test:]

Although the screen capture shown in Figure B lists what each of the command line switches does, the explanation is a bit sparse. That being the case, I am going to try to give you a better explanation of what each of the command line switches does.

/H

If you run the DCDIAG command with the /H parameter, it simply displays the DCDIAG command’s syntax in the manner shown in Figure B. If you look closely at the figure, you will notice that you can also use the /? Switch to display the command’s syntax.

/S

The /S parameter allows you to specify a home server. Essentially, this means that you can use the /S parameter to specify the name of the domain controller that you want to run DCDIAG against. As you may recall, when I ran the DCDIAG command in Figure A, I did not have to specify a home server. If you do not specify a home server, then DCDIAG will just pick one automatically.

There are a couple of instances in which a specified home server will be ignored. The DCPROMO and the Register In DNS tests are run locally rather than being run against a domain controller. Therefore, if you try to specify a home server for these tests, it will be ignored. I will talk more about these tests later on.

/N

The /N parameter allows you to specify a domain naming context. In case you aren’t familiar with this term, every domain is represented by a domain naming context. The domain naming context stores objects for the domain such as users, computers, groups, etc. You don’t have to specify a domain naming context, but if you choose to use one, you can enter it is NetBIOS, DNS (fully qualified domain name), or distinguished name (DN) form.

/U

Unless you are logged on as an administrator of the domain that you are testing, you will have to supply the DCDIAG command with a set of administrative credentials that it can use. As you no doubt know, administrative credentials typically consist of a username and a password. The /U switch is used to specify the username. Since you are entering the name of an account with domain admin permissions, you will have to enter the username in domain\username format.

/P

The other switch that is used when entering a set of credentials is the /P switch. As you have probably already figured out, you would follow the /P switch with the password for the account that you specified through the /U switch.

/A

An Active Directory is often grouped into sites. A site typically represents a collection of domain controllers that all have reliable, high speed connectivity between them. For example, if an organization has two different facilities, connected together by a WAN link, each of the two facilities would typically be configured to act as its own site since the computers within the facility are on a common LAN, but there is no LAN connection between the facilities.

If your organization is divided into sites, then you will be interested in the /A switch. Using this switch tells DCDIAG to test all of the domain controllers in the current site.

/E

The /E switch is similar to the /A switch, except that instead of telling DCDIAG to test all of the domain controllers in the current site, it tells DCDIAG to test every domain controller in the entire enterprise.

/Q

As you have already seen, the DCDIAG command’s output is pretty long. It can be easy for error messages to get lost in such a long output. If this happens to you, you can use the /Q switch to run DCDIAG in Quiet more, which will cause it to only list error messages.

/V

The /V switch is kind of the opposite of the /Q switch. While the /Q switch reduces the size of the output, the /V switch increases it. That way you can get more detailed (verbose) information on the problem that you are trying to correct.

/I

Sometimes DCDIAG will produce meaningless error messages that can really be confusing to less experienced administrators. If this happens to you, you can use the /I switch to tell DCDIAG to suppress any unimportant error messages.

Conclusion

In this article, I have introduced you to some of the basic commands used by the Domain Controller Diagnostic Utility. In Part 2, I will continue the discussion by showing you how to use a few additional command line switches, and how to specify specific tests that you would like to run.