Jasu

Admin KnowledgeBase Articles & Tutorials Authors Blogs Hardware Message Boards Newsletters RSS Software White Papers

2008-10-20T05:44:00.001-07:00

In the previous part of this article series, I explained that TRACERT could be used to help diagnose connectivity problems between local hosts, and hosts on remote networks. In that article, I showed you how to issue a basic TRACERT command, so in this article I will continue the discussion by showing you how you can interpret the results.

For demonstration purposes, I have performed a TRACERT against www.espn.com. The only reason why I chose this particular site is because it is one of the few sites that I know of off the top of my head that does not block ICMP traffic. You can see the output from the trace route below. I will be referring to this output throughout the rest of the article.

C:\Users\Administrator>TRACERT www.espn.com

Tracing route to www.espn.com [199.181.132.250] over a maximum of 30 hops:

1 2 ms 1 ms <1 ms 147.100.100.100

2 10 ms 10 ms 9 ms 208.104.224.1

3 9 ms 9 ms 9 ms 208.104.1.13

4 9 ms 8 ms 9 ms 208.104.0.13

5 10 ms 9 ms 10 ms 208.104.0.1

6 11 ms 14 ms 10 ms 165.166.125.193

7 11 ms 10 ms 11 ms gig-1-1-3.core01.ncchrl.infoave.net [165.166.22.61]

8 31 ms 31 ms 30 ms 64.200.130.17

9 38 ms 39 ms 40 ms hrndva1wcx2-pos15-3-oc48.wcg.net [64.200.240.213]

10 31 ms 31 ms 31 ms 64.200.249.170

11 31 ms 30 ms 31 ms 4.68.110.5

12 48 ms 35 ms 35 ms vlan99.csw4.Washington1.Level3.net [4.68.17.254]

13 32 ms 31 ms 33 ms ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157]

14 60 ms 53 ms 54 ms ae-2.ebr3.Chicago1.Level3.net [4.69.132.69]

15 86 ms 71 ms 70 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]

16 137 ms 103 ms 102 ms ae-2.ebr2.Seattle1.Level3.net [4.69.132.53]

17 95 ms 95 ms 95 ms ae-23-52.car3.Seattle1.Level3.net [4.68.105.36]

18 94 ms 95 ms 95 ms WALT-DISNEY.car3.Seattle1.Level3.net [4.71.152.22]

19 * * * Request timed out.

20 97 ms 95 ms 98 ms 199.181.132.250

Trace complete.

If you look at the TRACERT above, you will notice that each line of the output contains several different pieces of information. The first piece of information found on the leftmost side of each line is the hop number. As I explained in the previous article, TRACERT works by sending a ping request to the specified host. Initially, the requests TTL value is set to 1. This insures that the request will fail after the first hop. Information about the hop is presented, and then the ICMP request is transmitted again, but this time with the TTL value set to 2. The process is repeated over and over again, increasing the TTL value by 1 each time until the specified host is finally reached. In doing so, TRACERT is able to report how many hops the request had to make in order to reach the remote host. If you look at the last line of the output above, you will see that it begins with the number 20. That is because it took 20 hops to reach the specified host.

The next three pieces of information on each line display the amount of time that it took to reach the router or host that the particular line refers to. If you look through the list, you will notice that the time links generally increase with each hop. There are two things that you really need to know about the time links that are displayed.

First, three separate time lengths are displayed for each hop. As I mentioned before, trace route is based on the concept of sending multiple ICMP requests. When we worked with the ping command earlier in this article series, you saw the ping command always returned four different values as a way of measuring packet loss. The same concept applies to trace route, except that the length of time the request took is measured three times instead of four.

The second thing that you need to know about the response times are that an asterisk indicates that a request has timed out. This may or may not indicate a problem, depending on how the asterisk appears. If you look at hop number 19 in the output above, you will notice that all three response time values are presented as asterisks. When you see three asterisks in a row, it usually means that the device that is being pinged on at hop has its firewall configured to reject ICMP packets this will cause each of the timers to timeout, and the final column will simply display the words Request Timed Out.

Keep in mind though that although this is usually the case, it is not the only possibility. Trace route will also display three asterisks when the device in question is unreachable. Of course that raises the question of how you can tell the difference between a site that blocks ICMP packets, and a link failure? Well, it can be a little tricky.

At first glance, a link failure looks identical to what you see when a router or a host blocks ICMP requests. When a failure occurs, you are not going to see an error message. In fact, the process ends with the standard Trace Complete message.

There are two good signs that a link failure has occurred. One sign is that beyond a certain point in the trace, every result that is returned times out. Another sign of a link failure is that the TRACERT proceeds for a full 30 hops. Neither of these conditions guarantee that a link failure has occurred even when they occur together. For example, my Web site (www.brienposey.com) is working fine at the moment, and yet when I run a TRACERT against it, both of these symptoms show up, as shown in the output below:

C:\Users\Administrator>TRACERT www.brienposey.com

Tracing route to www.brienposey.com [24.235.10.4]

over a maximum of 30 hops:

1 1 ms 1 ms <1 ms 147.100.100.100

2 8 ms 12 ms 8 ms 208.104.224.1

3 9 ms 8 ms 9 ms 208.104.1.9

4 10 ms 9 ms 8 ms 208.104.0.9

5 10 ms 12 ms 11 ms 208.104.0.5

6 12 ms 10 ms 9 ms 165.166.18.1

7 15 ms 23 ms 13 ms gig2-2-1.c01.scclma.infoave.net [165.166.22.17]

8 13 ms 12 ms 13 ms 66.192.166.9

9 31 ms 30 ms * peer-01-ge-0-0-0-1.asbn.twtelecom.net [64.129.249.10]

10 56 ms 57 ms 55 ms bb2-p6-0.ipltin.sbcglobal.net [151.164.242.59]

11 55 ms 53 ms 55 ms ded2-g8-0.ipltin.sbcglobal.net [151.164.42.159]

12 59 ms 56 ms 56 ms Winnet-1148485.cust-rtr.ameritech.net [66.73.221.254]

13 64 ms 63 ms 68 ms 216-24-2-237.ip.win.net [216.24.2.237]

14 68 ms 68 ms 64 ms fa0-0.cust-gw2.noc.win.net [216.24.30.69]

15 * * * Request timed out.

16 * * * Request timed out.

17 * * * Request timed out.

18 * * * Request timed out.

19 * * * Request timed out.

20 * * * Request timed out.

21 * * * Request timed out.

22 * * * Request timed out.

23 * * * Request timed out.

24 * * * Request timed out.

25 * * * Request timed out.

26 * * * Request timed out.

27 * * * Request timed out.

28 * * * Request timed out.

29 * * * Request timed out.

30 * * * Request timed out.

Trace complete.

If you see an output like the one above, it may indicate that a link failure has occurred, but it does not guarantee it. The only way to know for sure is to try running a TRACERT against multiple sites, and see if you keep getting the same types of results. Keep in mind that higher numbered hops are further away from you. The further away a failure is, the harder it will be to diagnose because tests of other sites may take alternate routes. When you perform TRACERT tests against multiple sites, you will have to look at the routes that were actually taken to determine whether or not a link failure is occurring.

The final piece of information displayed on each row is the identity of the router or host that responded to the ICMP request. TRACERT will identify each host or router by name whenever possible, but you will not always get a full name resolution. For example, if you look at the output above, you can see that about half of the routers are identified by name, while the others are not. That in and of itself is not usually a big deal.

What you might find interesting is that the host that you are tracing the route to is not always going to be identified. For example, if you look at the very beginning of the first sample output above, you will notice that we entered the command TRACERT WWW.ESPN.COM. Immediately after doing so, TRACERT resolved www.espn.com to the IP address 199.181.132.250. If you skip ahead to the end of the sample output, you will notice that TRACERT eventually reaches its destination, but it does not identify the destination by name (at least not in this case).

This behavior is not problematic, it is by design. The reason why I showed you this is so that you would not try to perform a TRACERT to a site, and think that the process failed because the destination host is not identified by name.
Conclusion

In this article, I have shown you how to decipher the output of a TRACERT. In the next article in this series, I will show you how to use the Route command to examine a machine’s routing tables.

Deploying Vista – Part 10: Understanding the Windows Preinstallation Environment

2008-10-20T05:41:00.000-07:00

What is Windows PE?

Basically, Windows PE is a minimal version of Windows you can use to boot a bare-metal system (a computer with no operating system installed) and then connect to a network share, download the installation files for the full version of Windows, launch Setup.exe, and install Windows on the computer. Why do we need Windows PE to do this? Well, it’s simple: you’ve got a file server over there with a shared folder on it that contains the Windows installation files, and you’ve got a bare-metal system over here with no operating system on it, and you’ve got them both connected to the network, so you turn on your bare-metal system and…well, how is a computer with no operating system on it supposed to be able to connect to a shared folder over the network and launch Setup.exe from that folder?

In the old days, we used a network boot floppy to make this happen. This was a bootable floppy disk from which you could run a network-aware version of MS-DOS, and to install, say, Windows 95, you would stick the floppy in your bare-metal system, turn the computer on, boot to DOS, and then manually (or automatically by launching a script) connect to the installation share on the network and run Setup.exe to begin the process of downloading the Windows installation files to the computer and running Setup on it to install Windows. Unfortunately, network boot floppies are no longer viable for a variety of reasons including lack of support for the NTFS file system, lack of support for 32- or 64-bit Windows device drivers, limited TCP/IP networking capabilities, and other reasons. What worked fine for installing Windows 95 or Windows 98 onto computers just doesn’t cut it anymore with Windows Vista.

By contrast, using the Windows AIK you can now create Windows PE boot media that supports NTFS, supports 32- and 64-bit Windows drivers, has full TCP/IP capabilities and which can be booted from a CD, a DVD, or even a USB flash drive. Then once you have booted your bare-metal system, you can manually (or automatically by using a script) connect to a network share that has the Windows Vista installation files stored on it and launch Setup.exe to install Vista onto the computer in completely unattended fashion using an answer file you created using Windows SIM.
Limitations of Windows PE

This doesn’t mean Windows PE can do everything however. For example, while Windows PE is a stripped-down version of the Windows operating system and provides you with a command prompt and can do networking and has a registry and so on, you can’t use it as your daily operating system for the simple reason that it automatically stops working and automatically after 72 hours of use. Windows PE also doesn’t support installing applications that use Windows Installer (.msi) files, and it doesn’t include the .NET Framework or the Common Language Runtime (CLR), so you really can’t run any office productivity applications on it. Windows PE also supports only a limited subset of the full Win32 application programming interfaces (APIs) so you really can’t develop useful applications to run on it either. So while Window PE is indeed Windows itself, it’s a very stripped-down version of Windows, not the full-blown version you’re used to working with each day.

All these limitations mean that Windows PE is really only useful for two things: to boot bare-metal systems so you can install Windows on them, and to boot into the Windows Recover Environment (WinRE) in order to troubleshoot a computer that has problems with its Windows installation. Actaully, Windows PE is used for one additional thing: each time you install Windows Vista (or Windows Server 2008) on a system, the very first phase of Setup is actually Windows PE at work.
Examining Windows PE Tools

As you can see from Figure 1 below, when Windows PE initializes it displays a command prompt.

Figure 1: The Windows PE command prompt

This command prompt is the only user-interface that Windows PE provides—there is no desktop and no GUI tools in Windows PE. There are a number of command-line tools available in Windows PE however, and these include the following:

This tool can be used to edit the boot configuration data (BCD) store, a store that describes boot applications and boot application settings. The BCD store in Windows Vista and Windows Server 2003 replaces the Boot.ini used by earlier versions of Windows.

Bootsect - Used to restore your computer’s boot sector (replaces FixFAT and FixNTFS used by previous versions of Windows)

DiskPart – Used to create and format partitions and volumes and perform other disk management tasks.

Drvload - Used for adding out-of-box drivers to a booted Windows PE image.

Oscdimg - Used for creating an .iso image of Windows PE so you can burn the operating system onto CD or DVD media to create a customized, bootable Windows PE CD or DVD.

PEImg - Used to create or modify a Windows PE image by adding drivers, importing packages, and so on.

In addition to the above tools there are others that are built into Windows PE. Plus you can add additional command-line tools to your customized Windows PE CD or DVD. For example, in the next article of this series we’ll walk through the steps of creating a bootable Windows PE CD that includes the ImageX.exe tool on it, and later on I’ll show you how you can use this tool on a Windows PE CD to capture an image of a sysprepped master computer so you can deploy the captured image onto bare-metal destination computers—a deployment scenario called image-based deployment that is popular with OEMs and large enterprises. But that is for next time.

Deploying Vista – Part 9: Automating the Machine OOBE

2008-10-20T05:30:00.000-07:00

Opening your Minimal Answer File

On your technician computer, start Windows SIM, open your Vista SP1 Enterprise install image in the Image Pane, and then in the Answer File pane open the autounattend.xml file you created in article seven previously (see Figure 1):

Figure 1: Minimal answer file created in article seven earlier
Specifying a User Name and Password

In the Windows Image pane, expand the Components node to display the Microsoft-Windows-Shell-Setup node beneath it. Then expand Microsoft-Windows-Shell-Setup node to display the UserAccounts, then LocalAccounts, then LocalAccount. Right-click on LocalAccount and select Add Setting to pass 7 oobeSystem as shown in Figure 2:

Figure 2: Adding the Microsoft-Windows-Shell-Setup\UserAccounts\LocalAccounts\LocalAccounts component to the oobeSystem configuration pass of your answer file.

In the Answer File pane you should now have the LocalAccounts component selected under the oobeSystem pass.

Now in the Properties pane, type the user’s name (logon and display names), Administrators for the user’s local group, and an optional description (Figure 3):

Figure 3: Specifying a local user account and password

Note that we’re only creating a local user account here on the computer. If the computer will belong to a domain, you would typically create the domain user account ahead of time in Active Directory. You still have to create a local computer account as a fallback however, and it should belong to the local Administrators group on the machine since the default Administrator account is disabled in Vista.

In the Answer File, select the Password component beneath LocalAccount. Then in the Properties pane type a password for the user account you’re creating on the computer (Figure 4):

Figure 4: Assigning a password to the local user account you are creating on the computer
Specifying a Computer Name and Default Theme

Back in the Windows Image pane, right-click on the Microsoft-Windows-Shell-Setup node and select Add Setting to pass 4 specialize as shown in Figure 5:

Figure 5: Adding the Microsoft-Windows-Shell-Setup component to the specialize configuration pass of your answer file

In the Answer File pane you should now have the Microsoft-Windows-Shell-Setup component selected under the specialize pass.

Now in the Properties pane, type a name for the computer in the value box to the right of the ComputerName setting (Figure 6):

Figure 6: Specifying a name for the computer

Now wait just a minute. Why do we have to add the Microsoft-Windows-Shell-Setup component to our answer file when we did this in the previous section above where we added a local user account for the computer? Because (a) you can add many answer file components to more than one configuration pass and (b) the computer name can only be specified using an answer file in the specialize configuration pass and not during the oobeSystem configuration pass (see Figure 7):

Figure 7: There is no ComputerName setting under Microsoft-Windows-Shell-Setup for the oobeSystem configuration pass!

Now let’s specify the default Aero theme. In the Answer File pane, select Microsoft-Windows-Shell-Setup\Themes. Then in the Properties pane type the path to the default Aero theme as shown in Figure 8:

Figure 8: Specifying the default Aero theme
Specifying the Protect Your PC and Network Location Settings

Now let’s configure the Protect Your PC setting, which determines whether Vista will automatically download and install updates or not. In the Windows Image pane, right-click on OOBE under Microsoft-Windows-Shell-Setup and select Add Setting to pass 7 oobeSystem (Figure 9)

Figure 9: Adding the Microsoft-Windows-Shell-Setup\OOBE component to the oobeSystem configuration pass of your answer file

In the Answer File pane you should now have the Microsoft-Windows-Shell-Setup\OOBE component selected under the oobeSystem pass.

In the Properties pane, click in the value box to the right of the ProtectYourPC setting and type 1 to specify that Vista should automatically download and install updates when they become available.

Then in the Properties pane again, click the value box to the right of the NetworkLocation setting until a drop-down arrow appears. Click the arrow and select Work to indicate that the computer will be used at work (Figure 10):

Figure 10: The computer will automatically download and install updates when they become available on Windows Update, and the network location is configured as Work
Specifying the Time Zone

We’re almost done. In the Answer File pane, under oobeSystem, select the Microsoft-Windows-Shell-Setup component. Then in the Properties pane, I would type Canada Central Standard Time in the value box to the right of the TimeZone setting, but you would probably type something different—see this page on TechNet for what you can type here. The result is shown in Figure 11:

Figure 11: Specifying your time zone
Validating and Testing the Answer File

Now from Windows SIM’s menu, select Tools, then Validate Answer File. You should only see a series of Information messages in the Messages pane, and these you can ignore. If you see any Error or Warning messages, double-click on them and correct any errors you find in your answer file until validation succeeds.

Save your modified answer file using the same file name (autounattend.xml) as before. Then copy it to a USB flash drive and try using it together with your Vista SP1 Enterprise product DVD to perform an Unattended Install From DVD installation of Vista on a bare-metal system. Your installation should proceed in a completely unattended fashion, after which Vista will run is performance check (this can’t be prevented) and then you’ll be presented with a logon screen for Bob Smith. Bob can then type his password, log on, and start working on his computer.
Figure 11: Specifying your time zone
Validating and Testing the Answer File

10 Windows Server 2008 Netsh commands you should know

2008-08-30T00:59:00.000-07:00

Taking a look at ten Netsh commands that every Windows administrator should know.

Introduction

I have written a number of different Netsh articles and other authors have published their own Netsh articles. This just shows how important and innovative Netsh really is. In this article, I will cover 10 Netsh commands that every Windows admin should know. In my opinion. Netsh is so powerful and flexible; I cannot choose the “most important” Netsh commands as the importance of a command will vary from admin to admin. What I can do is to choose the 10 commands that I feel will either show you valuable information or will help you out when you are in trouble. Keep in mind that these commands can be scripted (as they are all command line tools) so whatever you can do with just an individual command on a single machine, you could write a script to perform that command on all machines in your network.
What is Netsh?

Microsoft Windows Netsh is a command line scripting utility. With Netsh, you can view or change the network configuration of your local computer or a remote computer. You can manually run Netsh commands or you can create batch files or scripts to automate the process. Not only can you run these commands on your local computer but also on remote computers, over the network.

Netsh also provides a scripting feature that allows you to run a group of commands in batch mode against a specified computer. With netsh, you can save a configuration script in a text file for archival purposes or to help you configure other computers.

Netsh is not “new” with Windows Server 2008 or Windows Vista. Netsh has been around for a long time. Netsh commands are available in Windows 2000, XP, and Windows Server 2003. What is new are a number of options for Netsh with Windows Server 2008 and Vista. Additionally, I feel that Netsh is underutilized by admins and most admins are not aware of the new Windows Server 2008 and Vista Netsh enhancements. It is my hope to educate Windows admins about the new netsh features and the power of netsh in this article.
What is different about Windows Server 2008 netsh vs. Windows XP?

There are a number of differences even at the core command level between the Windows XP version of netsh and the Windows Server 2008 netsh. To compare these, I ran “netsh /?” in each operating system. While Windows XP has “routing” listed as a context and Windows Server 2008 does not, that is the only context that Win 2008 lacks (and that is included in the Win 2008 RAS context). Otherwise, Windows Server 2008 has the following netsh context options available that Windows XP does not:
dhcp
dhcpclient
http
ipsec
lan
nap
netio
rpc
winhttp

Thus, as you can see, there are many more “context” / options available in Window Server 2008.

With no more delay, let’s get started with our Netsh top 10 Netsh commands that every admin should know.
#10 – How to get help

Every Windows admin should know how to get guided help with netsh. This is easy – just use the “/?” command to be guided through what you are trying to do. For example, to show all netsh contexts (categories of options), just type: netsh /?

Figure 1: Results of netsh /? help options

From there, you can select a context and be guided through configuring or showing options in that context. For example, say that I typed netsh lan /?, I would see:

Figure 2: Results of netsh lan /?

From there, I can continue with the guided help by doing-

netsh lan show /?

And, from there, I would see that I can show interfaces with-

netsh lan show interfaces

Being able to guide yourself through the many netsh commands using /? is a very valuable skill.
#9 – Supplying remote machine names and credentials

If you run netsh /? you will see that you can supply the remote machine name & IP address and credentials for the remote machine you will run netsh against. The options are “-r” for the machine, “-u” for the username, and “-p” for the password. Here is an example:

netsh -r WinXP-1 -u winxp-1\administrator -p My!Pass1 interface ip show config

As you can see, I supplied the remote machine name, remote username, and password which allowed me to perform this command over the network. You can perform any of the commands shown here over the network as long as the remote machine supports that command (different operating systems will use different variations of commands).
#8 – Run Netsh in interactive mode or with a script

Netsh can be run either interactively (just you typing commands manually) or when using scripting. Say that you wanted to manually step through some commands on your local machine or remote machine. You could just start by typing netsh at the command line and you would see:

netsh>

From there, you can enter all the netsh commands you want, or even tell netsh to connect to a remote machine with set machine.

On the other hand, you could use netsh –f and specify a script that netsh would use.
#7 – Open a port on your firewall

With netsh, you can quickly and easily open a port on your firewall if you know the right command. Here is an example of opening port 445-

netsh firewall set portopening tcp 445 smb enable

If the command was successful, you should get a response of “Ok.”
#6 – Export your current network configuration to a file and import it

With netsh, exporting and importing your IP address configuration is easy – unlike in the GUI interface. To export your configuration, just do:

netsh –c interface dump > test.txt

Figure 3: Export of IP address configuration and viewing the file

Later on this machine or on a different machine, you could import this configuration with-

netsh –f test.txt
#5 – Try out the latest Netsh uses

As mentioned above, there are a lot of new features in Windows Server 2008 as it pertains to netsh.

Here are the new categories that I see on my Windows Server 2008 system:
dhcp
dhcpclient
http
ipsec
lan
nap
netio
rpc
winhttp

For example, you can configure not only your DHCP client but also your DHCP server. You can configure IPSec encryption, the network access protection (NAP) client, and many more!

As you add other roles & features to your server, you will have additional contexts available to you. For example, if you add the network policy server to Windows Server 2008, you will have “nps” as a net netsh context that can be configured.

For the official Microsoft Windows Server 2008 netsh documentation, see this URL:

Microsoft TechNet- Windows Server 2008 -Netsh Technical Reference
#4 – TCP/IP troubleshooting and interface resets

There are a number of things you can do with netsh to troubleshoot and reset your TCP/IP network interface. Here are some examples:
Reset all IP protocol stack configurations on your interface and send the output to a log file- netsh int ipv4 reset resetlog.txt
Install the TCP/IP protocol- netsh int ipv4 install
UnInstall the TCP/IP protocol- netsh int ipv4 uninstall
#3 – Configure the Windows Advanced Firewall

In my previous article, How to Configure Windows 2008 Advanced Firewall with the NETSH CLI, I discussed how you can now configure the new Windows advanced (bi-directional) firewall using the new advfirewall networking context settings using netsh in Windows Server 2008 and Windows Vista. Of course, you can also configure the traditional Windows firewall. Here are some examples:
Show all firewall rules - netsh advfirewall firewall show rule name=all
Delete an inbound advanced firewall rule for port 21 - netsh advfirewall firewall delete name rule name=all protocol=tcp localport=21
Export Windows Advanced Firewall settings - netsh advfirewall export “c:\advfirewall.wfw”

Perhaps the most common command you might use is the command to enable or disable your Windows firewall, like this:

netsh firewall set opmode disable

or

netsh firewall set opmode enable

However, for more specific information & examples, please see my article, above.
#2 – Configure Wireless Settings

In another article, Configuring Windows Server 2008 & Windows Vista Wireless connections from the CLI using netsh wlan, I discussed how you can now configure wireless networking context settings using netsh in Windows Server 2008 and Windows Vista. Here are some examples:
Connect to an already defined wireless network- netsh wlan connect ssid=”mySSID” name=”WLAN-Profil1”
Show your current wireless settings - netsh wlan show settings
Add an already exported wireless network profile - netsh wlan add profile filename="Wireless Network Connection-BOW.xml"

Troubleshooting Connectivity Problems on Windows Networks (Part 1)

2008-08-20T20:28:00.000-07:00

This article series will explain various troubleshooting techniques that you can use when machines on a Windows network have difficulty communicating with each other.

Today’s network hardware and software is more reliable than ever but even so, things do occasionally go wrong. In this article series, I am going to discuss some troubleshooting techniques that you can use when a host on your Windows network has trouble communicating with other network hosts. For the sake of those with less experience in working with the TCP/IP protocol, I’m going to start with the basics, and then work toward the more advanced techniques.

Verify Network Connectivity

When one host has trouble communicating with another, the first thing that you must do is to gather some information about the problem. More specifically, you need to document the host’s configuration, find out if the host is having trouble communicating with any other machines on the network, and find out if the problem effects any other hosts.

For example, suppose that a workstation is having trouble communicating with a particular server. That in itself doesn’t really give you a lot to go on. However, if you were to dig a little bit deeper into the problem and found out that the workstation couldn’t communicate with any of the network servers, then you would know to check for a disconnected network cable, a bad switch port, or maybe a network configuration problem.

Likewise, if the workstation were able to communicate with some of the network servers, but not all of them, that too would give you a hint as to where to look for the problem. In that type of situation, you would probably want to check to see what the servers that could not be contacted had in common. Are they all on a common subnet? If so, then a routing problem is probably to blame.

If multiple workstations are having trouble communicating with a specific server, then the problem probably isn’t related to the workstations unless those workstations were recently reconfigured. More than likely, it is the server itself that is malfunctioning.

The point is that by starting out with a few basic tests, you can gain a lot of insight into the problem at hand. The tests that I am about to show you will rarely show you the cause of the problem, but they will help to narrow things down so that you will know where to begin the troubleshooting process.

PING

PING is probably the simplest TCP/IP diagnostic utility ever created, but the information that it can provide you with is invaluable. Simply put, PING tells you whether or not your workstation can communicate with another machine.

The first thing that I recommend doing is opening a Command Prompt window, and then entering the PING command, followed by the IP address of the machine that you are having trouble communicating with. When you do, the machine that you have specified should produce four replies, as shown in Figure A.

Figure A: The specified machine should generate four replies

The responses essentially tell you how long it took the specified machine to respond with thirty two bytes of data. For example, in Figure A, each of the four responses were received in less than four milliseconds.

Typically, when you issue the PING command, one of four things will happen, each of which has its own meaning.

The first thing that can happen is that the specified machine will produce four replies. This indicates that the workstation is able to communicate with the specified host at the TCP/IP level.

The second thing that can happen is that all four requests time out, as shown in Figure B. If you look at Figure A, you will notice that each response ends in TTL=128. TTL stands for Time To Live. What this means is that each of the four queries and responses must be completed within 128 milliseconds. The TTL is also decremented once for each hop on the way back. A hop occurs when a packet moves from one network to another. I will be talking a lot more about hops later on in this series.

Figure B: If all four requests time out, it could indicate a communications failure

At any rate, if all four requests have timed out, it means that the TTL expired before the reply was received. This can mean one of three things:

Communications problems are preventing packets from flowing between the two machines. This could be caused by a disconnected cable, a bad routing table, or a number of other issues.
Communications are occurring, but are too slow for PING to acknowledge. This can be caused by extreme network congestion, or by faulty network hardware or wiring.
Communications are functional, but a firewall is blocking ICMP traffic. PING will not work unless the destination machine’s firewall (and any firewalls between the two machines) allow ICMP echos.

A third thing that can happen when you enter the PING command is that some replies are received, while others time out. This can point to bad network cabling, faulty hardware, or extreme network congestion.

The fourth thing that can occur when pinging a host is that you receive an error similar to the one that is shown in Figure C.

Figure C: This type of error indicates that TCP/IP is not configured correctly

The PING: Transmit Failed error indicates that TCP/IP is not configured correctly on the machine on which you are trying to enter the PING command. This particular error is specific to Vista though. Older versions of Windows produce an error when TCP/IP is configured incorrectly, but the error message is “Destination Host Unreachable”

What if the PING is Successful?

Believe it or not, it is not uncommon for a ping to succeed, even though two machines are having trouble communicating with each other. If this happens, it means that the underlying network infrastructure is good, and that the machines are able to communicate at the TCP/IP level. Typically, this is good news, because it means that the problem that is occurring is not very serious.

If normal communications between two machines are failing, but the two machines can PING each other successfully (be sure to run the PING command from both machines), then there is something else that you can try. Rather than pinging the network host by IP address, try replacing the IP address with the host’s fully qualified domain name, as shown in Figure D.

Figure D: Try pinging the network host by its fully qualified domain name

If you are able to ping the machine by its IP address, but not by its fully qualified domain name, then you most likely have a DNS issue. The workstation may be configured to use the wrong DNS server, or the DNS server may not contain a host record for the machine that you are trying to ping.

If you look at Figure D, you can see that the machine’s IP address is listed just to the right of its fully qualified domain name. This proves that the machine was able to resolve the fully qualified domain name. Make sure that the IP address that the name was resolved to is correct. If you see a different IP address than the one that you expected, then you may have an incorrect DNS host record.

Troubleshooting Logon Problems

2008-08-13T03:07:00.000-07:00

This article discusses some of the more common causes of logon failures in Active Directory environments.

Logging into a computer is such a routine part of the day that it is easy to not even think about the login process. Even so, things can and occasionally do go wrong when users log into Windows. In this article, I will talk about some of the things that can cause logon failures, and show you how to get around those problems.

Before I Begin

Before I get started, I just want to quickly mention that in order to provide as much useful information as possible, I am going to avoid talking about the most obvious causes of logon failures. This article assumes that before you begin the troubleshooting process, you have checked to make sure that the user is entering the correct password, the user's password has not expired, and that there are no basic communications problems between the workstation and the domain controller.

The System Clock

It may seem odd, but a workstation's clock can actually be the cause of a logon failure. If the clock is more than five minutes different from the time on your domain controllers, then the logon will fail.

In case you are wondering, the reason for this has to do with the Kerberos authentication protocol. At the beginning of the authentication process, the user enters their username and password. The workstation then sends a Kerberos Authentication Server Request to a the Key Distribution Server. This Kerberos Authentication Server Request contains several different pieces of information, including:

The user’s identification
The name of the service that the user is requesting (in this case it’s the Ticket Getting Service)
An authenticator that is encrypted with the user’s master key. The user’s master key is derived by encrypting the user’s password using a one way function.

When the Key Distribution Server receives the request, it looks up the user’s Active Directory account. It then calculates the user’s master key and uses it to decrypt the authenticator (also known as pre authentication data).

When the user’s workstation created the authenticator, it placed a time stamp within the encrypted file. Once the Key Distribution Server decrypts this file, it compares the time stamp to the current time on its own clock. If the time stamp and the current time are within five minutes of each other, then the Kerberos Authentication Server Request is assumed to be valid, and the authentication process continues. If the time stamp and the current time are more than five minutes apart, then Kerberos assumes that the request is a replay of a previously captured packet, and therefore denies the logon request. When this happens, the following message is displayed:

The system cannot log you on due to the following error: There is a time difference between the client and server. Please try again or consult your system administrator.

The solution to the problem is simple; just set the workstation’s clock to match the domain controller’s clock.

Global Catalog Server Failures

Another major cause of logon problems is a global catalog server failure. A global catalog server is a domain controller that has been configured to act as a global catalog server. Global catalog servers contain a searchable representation of every object in every domain of the entire forest.

When the forest is initially created, the first domain controller that you bring online is automatically configured to act as a global catalog server. The problem is that this server can become a single point of failure, because Windows does not automatically designate any other domain controllers to act as global catalog servers. If the global catalog server fails, then only domain administrators will be able to log into the Active Directory.

Given the global catalog server’s importance, you should work to prevent global catalog server failures. Fortunately, you can designate any or all of your domain controllers to act as global catalog servers. Keep in mind though that you should only configure all of your domain controllers to act as global catalog servers if your forest consists of a single domain. Having multiple global catalog servers is a good idea even for forests with multiple domains, but figuring out which domain controllers should act as global catalog servers is something of an art form. You can find Microsoft’s recommendations here.

If your global catalog server has already failed, and nobody can log in, then the best thing that you can do is work to return the global catalog server to a functional state. There is a way of allowing users to log in even though the global catalog server is down, but there are security risks associated with doing so.

If the Active Directory is running in native mode, then the global catalog server is responsible for checking user’s universal group memberships. If you choose to allow users to logon during the failure, then universal group memberships will not be checked. If you have assigned explicit denials to members of certain universal groups, then those denials will not be in effect until the global catalog server is brought back online.

If you decide that you must allow users to log on, then you will have to edit the registry on each of your domain controllers. Keep in mind that editing the registry is dangerous, and that making a mistake can destroy Windows. I therefore recommend making a full system backup before continuing.

With that said, open the Registry Editor and navigate through the registry tree to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Now, create a new DWORD value named IgnoreGCFailures, and set the value to 1. You will have to restart the domain controller after making this change.

DNS Server Failure

If you suddenly find that none of your users can log into the network, and your domain controllers and global catalog servers seem to be functional, then a DNS server failure might have occurred. The Active Directory is completely dependent on the DNS services.

The DNS server contains host records for each computer on your network. The computers on your network use these host records to resolve computer names to IP addresses. If a DNS server failure occurs, then host name resolution will also fail, eventually impacting the logon process.

There are two things that you need to know about DNS failures in regard to troubleshooting logon problems. First, the logon failures may not happen immediately. The Windows operating system maintains a DNS cache, which includes the results of previous DNS queries. This cache prevents workstations from flooding DNS servers with name resolution requests for the same objects over and over.

In many cases, workstations will have cached the IP addresses of domain controllers and global catalog servers. Even so, items in the DNS cache do eventually expire and will need to be refreshed. You will most likely start noticing logon problems when cached host records begin to expire.

The other thing that you need to know about DNS server failures is that often times there are plenty of other symptoms besides logon failures. Unless machines on your network are configured to use a secondary DNS server in the event that the primary DNS server fails, the entire Active Directory environment will eventually come to a grinding halt. Although there are exceptions, generally speaking, the absence of a DNS server on an Active Directory network basically amounts to a total communications breakdown.

Conclusion

Although I have discussed some of the major causes of logon failures on Active Directory networks, an important part of the troubleshooting process is to look at how widespread the problem is. For example, if only a single host on a large network is having logon problems, then you can probably rule out DNS or global catalog failures. If a DNS or a global catalog failure were to blame, then the problem would most likely be much more wide spread. If the problem is isolated to a single machine, then the problem is most likely related to the machine’s configuration, connectivity, or to the user’s account.

OSI Reference Model: Layer 1 hardware

2008-08-12T04:52:00.000-07:00

A description of layer 1 of the OSI reference model and the hardware which relates to that layer.

The Open System Interconnect (OSI) reference model is a model, developed by the International Standards Organization (ISO), which describes how data from an application on one computer can be transferred to an application on another computer. The OSI reference model consists of seven conceptual layers which each specify different network functions. Each function of a network can be assigned to one, or perhaps a couple of adjacent layers, of these seven layers and is relatively independent of the other layers. This independence means that one layer does not need to be aware of what the implementation of an adjacent layer is, merely how to communicate with it. This is a major advantage of the OSI reference model and is one of the major reasons why it has become one of the most widely used architecture models for inter-computer communications.

The seven layers of the OSI reference model, as shown in Figure 1, are:

Application
Presentation
Session
Transport
Network
Data link
Physical

Figure 1: Diagram of the OSI reference model layers, courtesy of catalyst.washington.edu

Over the next few articles I will be discussing each layer of the model and the networking hardware which relates to that layer. This article, as you have probably guessed from the title, will discuss layer 1; the physical layer.

While many people may simply state that all networking hardware belongs exclusively in the physical layer, they are wrong. Many networking hardware devices can perform functions belonging to the higher layers as well. For example, a network router performs routing functions which belong in the network layer.

What does the physical layer include? Well, the physical layer involves the actual transmission of signals over a medium from one computer to another. This layer includes specifications for the electrical and mechanical characteristics such as: voltage levels, signal timing, data rate, maximum transmission length, and physical connectors, of networking equipment. For a device to operate solely in the physical layer, it will not have any knowledge of the data which it transmits. A physical layer device simply transmits or receives data.

There are four general functions which the physical layer is responsible for. These functions are:

Definitions of hardware specifications
Encoding and signaling
Data transmission and reception
Topology and physical network design

Definitions of hardware specifications

Each piece of hardware in a network will have numerous specifications. If you read my previous article titled Copper and Glass: A Guide to Network Cables [link this title to my previous article of that title], you will learn about some of the more common specifications which apply to network cables. These specifications include things like the maximum length of a cable, the width of the cable, the protection from electromagnetic interference, and even the flexibility.

Another area of hardware specifications are the physical connectors. This includes both the shape and size of the connectors as well as the pin count and layout, if appropriate.

Encoding and signaling

Encoding and signaling is a very important part of the physical layer. This process can get quite complicated. For example, let's look at Ethernet. Most people learn that signals are sent in '1's and '0's using a high voltage level and a low voltage level to represent the two states. While this is useful for some teaching purposes, it is not correct. Signals over Ethernet are sent using Manchester encoding. This means that '1's and '0's are transmitted as rises and falls in the signal. Let me explain.

If you were to send signals over a cable where a high voltage level represents a '1' and a low voltage signal represents a '0' the receiver would also need to know when to sample that signal. This is usually done with a separate clock signal being transmitted. This method is called a Non-return to Zero (NRZ) encoding, and has some serious drawbacks. First, if you do include a separate clock signal you are basically transmitting two signals and doubling the work. If you don't want to transmit the clock signal, you could include an internal clock in the receiver but this must be in near perfect synchronization with the transmitter clock. Let's assume you can synchronize the clocks, which becomes much harder as the transmission speed increases, there is still the problem of keeping this synchronization when there is a long stretch of the same bit being transmitted; it is the transitions which help synchronize the clocks.

The limitations of the NRZ encoding can be overcome by technology developed in the 1940s at the University of Manchester [link University of Manchester to http://www.manchester.ac.uk/], in Manchester, UK. Manchester encoding combines the clock signal with the data signal. While this does increase the bandwidth of the signal, it also makes the successful transmission of the data much easier and reliable.

A Manchester encoded signal, transmits data as a rising or falling edge. Which edge represents the '1' and which represents the '0' must be decided first, but both are considered Manchester encoded signals. Ethernet and IEEE standards use the rising edge as a logical '1'. The original Manchester encoding used the falling edge as a '1'.

One situation which you may be thinking about is that if you need to transmit two '1's in a row the signal will already be high when you need to transmit the second '1'. This isn't the case because the rising or falling edge which represents data is transmitted in the middle of the bit boundaries; the edge of the bit boundaries either contain a transition or do not, which puts the signal in the right position for the next bit to be transmitted. The end result is that at the center of every bit is a transition, the direction of the transition represents either a '1' or a '0' and the timing of the transition is the clock.

While there are many other encoding schemes, many of which are much more advanced than NRZ or Manchester encoding, the simplicity and reliability of Manchester encoding has kept it a valuable standard still widely in use.

Data transmission and reception

Whether the network medium is an electrical cable, an optical cable, or radio frequency, there needs to be equipment that physically transmits the signal. Likewise, there also needs to be equipment that receives the signal. In the case of a wireless network, this transmission and reception is done by highly designed antennas which transmit, or receive, signals at predefined frequencies with predefined bandwidths.

Optical transmission lines use equipment which can produce and receive pulses of light, the frequency of which is used to determine the logical value of the bit. Equipment such as amplifiers and repeaters, which are commonly employed in long-haul optical transmissions, are also included in the physical layer of the OSI reference model.

Topology and physical network design

The topology and design of your network is also included in the physical layer. Whether your network is a token ring [link token ring to http://en.wikipedia.org/wiki/Network_topology#Ring], star [link star to http://en.wikipedia.org/wiki/Network_topology#Star], mesh [link mesh to http://en.wikipedia.org/wiki/Network_topology#Mesh], or a hybrid topology [link hybrid topology to http://en.wikipedia.org/wiki/Network_topology#Hybrid_network_topologies], the decision of which topology to use was chosen with the physical layer in mind.

Also included in the physical layer is the layout of a high availability cluster, as described in my previous article titled High Assurance Strategies [link High Assurance Strategies to my previous article].

In general all you need to remember is that if a piece of hardware is not aware of the data being transmitted then it operates in the physical layer. In my next article I will discuss the Data link layer, what makes it different from it's adjacent layers and what hardware is included in it. As always, if you have any questions or comments on what I have written in this article feel free to send me an email.

OSI Reference Model: Layer 2 Hardware

2008-08-12T04:49:00.000-07:00

A discussion of the second layer of the OSI reference model from a hardware perspective.

In my last article, I introduced the Open System Interconnect (OSI) reference model and discussed it's first layer; the Physical Layer. In this article I will discuss the second layer, the Data Link Layer, from a hardware perspective.

The data link layer provides functional and procedural methods of transferring data between two points. There are five general functions which the Data Link layer is responsible for. These functions are:

Logical Link Control
Media Access Control
Data Framing
Addressing
Error Detection

Logical Link Control

The Logical Link Control (LLC) is usually considered a sublayer of the Data Link layer (DLL), as opposed to a function of the DLL. This LLC sublayer is primarily concerned with multiplexing protocols to be sent over Media Access Control (MAC) sublayer. The LLC does this by splitting up the data to be sent into smaller frames and adding descriptive information to these frames, called headers.

Media Access Control

Like LLC, the Media Access Control (MAC) is considered a sublayer of the DLL, as opposed to a function of the DLL. Included in this sublayer is what is known as the MAC address. The MAC address provides this sublayer with a unique identifier so that each network access point can communicate with the network. The MAC sublayer is also responsible for the actual access to the network cable, or communication medium.

Data Framing

If one were to simply send data out onto the network medium not much would happen. The receiver has to know how, and when, to read the data. This can happen in a number of ways and is the sole purpose of framing. In general terms, framing organizes the data to be transferred and surrounds this data with descriptive information, called headers. What, and how much, information these headers contain is determined by the protocol used on the network, like Ethernet.

The structure of a frame adhering to the Ethernet protocol is shown below in Figure 1.

Figure 1: Structure of an Ethernet frame (Courtesy: Wikipedia)

Addressing

Addressing in layer 2 happens, as I mentioned earlier, with the MAC address of the MAC sublayer. It is very important not to confuse this with network or IP addressing. It can be helpful to associate the MAC address with a specific network access point and the network or IP address associated with an entire device (i.e. a computer, server, or router).

Speaking of routers, keep in mind that routers operate in layer 3, not layer 2. Switches and hubs do operate in layer two, and therefore direct data based on layer 2 addressing (MAC addresses) and are unaware of IP or network addressing. And, just so that I don't get an inbox filled with complaints ... yes I know... some routers also include layer 2 functionality. I will discuss routers with layer 2 functionality in another future article.

Error Detection and Handling

Whenever data is sent over any kind of transmission medium, there exists a chance that the data will not be received exactly as it was sent. This can be due to many factors including interference and, in the case of long transmissions, signal attenuation. So, how can a receiver know if the data received is error free? There are several methods that can be implemented to accomplish this. Some of these methods are simple and somewhat effective – others are complicated and very effective.

Parity bits are an example of an error detection protocol that is simple and, despite its limited effectiveness, its use is widespread. A parity bit, simply put, is an extra bit added to a message. There are two options for the value of this bit. Which value is chosen depends on the flavor of parity bit detection that is in use. These two flavors are even and odd parity detection. If even parity is in use, then the parity bit is set to the value ('1' or '0') to make the number of '1's in the message even. Likewise, if odd parity is in use the parity bit is set to the value needed to make the number of '1's in the message odd.

When using parity bit error detection the receiver will check all '1's in the frame, including the parity bit. The receiver will have a setting for even or odd parity; if the number of '1's in the frame does not match this setting, an error is detected. Now this is great, but as I mentioned earlier the effectiveness of this error detection method is limited. It is limited because if there is an even number of errors in the frame then the evenness or oddness of the number of '1's will be maintained and this method will fail to detect any errors – thus the need for a more rigorous error detection method.

A checksum error detection method can give us more rigor especially if used with a parity bit method. A checksum method, as its name suggests, will basically check the sum of all the '1's in a message and check that value against the checksum value added by the sender to the message. While a checksum method can provide more rigor to your error detection efforts, there are still limitations. For example, a simple checksum cannot detect an even number of errors which sum to zero, an insertion of bytes which sum to zero, or even the re-ordering of bytes in the message. While there are some more advanced implementations of the checksum method, including Fletcher's checksum method, I will discuss an even more rigorous method here.

One of the most rigorous methods of error detection is the cyclic redundancy check (CRC). What a CRC does is convert the message to a polynomial where the value of the coefficients correspond to the bits in the message and then divide that polynomial by a predetermined, or standard, polynomial called a key. The answer, more specifically the remainder part of the answer, is what is sent along with the message to the receiver. The receiver performs the same polynomial division with the same key and then checks the answer. If the answers match, then the chances are pretty good that there were no errors. I say pretty good because there are a lot of possible polynomials one could use for a key and not all polynomials provide equally good error detection. As a general rule, longer polynomials provide better error detection but the mathematics involved with this are quite complex and as with many aspects of technology there is some debate as to which implementations of this method provide the best error detection.

Lastly, I would like to point out that these error detection methods are not limited to transmissions of data over a network medium; they can be used equally well in a data storage scenario where one wants to check that the data has not been corrupted.

In my next article I will discuss layer 3 of the OSI model. I will also explain in a little more detail why routers (mostly) belong in the 3rd layer and not the 2nd. And as always, if you have any questions about this or any previous article, please do not hesitate to email me and I will do my best to answer any and all questions.

OSI Reference Model: Layer 3 Hardware

2008-08-12T04:48:00.001-07:00

A discussion of the third layer of the OSI reference model, focusing mostly on routers and why they are usually placed in this layer.

In my last two articles I discussed the Open System Interconnect (OSI) reference model and its first two layers. In this article I will discuss the third layer; the network layer. The network layer is concerned with getting data from one computer to another. This is different from the data link layer (layer 2) because the data link layer is concerned with moving data from one device to another directly connected device. For example, the data link layer is responsible for getting data from the computer to the hub it is connected to, while the network layer is concerned with getting that same data all the way to another computer, possibly on the other side of the world.

The network layer moves data from one end point to another by implementing the following functions:

Addressing
Routing
Encapsulation
Fragmentation
Error handling
Congestion control

Addressing

Those who have read my previous article may be curious why layer 3 implements addressing when I also said that layer 2 implements addressing. To cure your curiosity, remember that I wrote that the layer 2 address (the MAC address) corresponds to a specific network access point as opposed to an address for an entire device like a computer. Something else to consider is that the layer 3 address is purely a logical address which is independent of any particular hardware; a MAC address is associated with particular hardware and hardware manufacturers.

An example of layer 3 addressing is the Internet Protocol (IP) addressing. An illustration of an IP address can be seen here in figure 1.

Figure 1: Illustration of an IP address (Source:Wikipedia.com)

Routing

It is the job of the network layer to move data from one point to its destination. To accomplish this, the network layer must be able to plan a route for the data to traverse. A combination of hardware and software routines accomplish this task known as routing. When a router receives a packet from a source it first needs to determine the destination address. It does this by removing the headers previously added by the data link layer and reading the address from the predetermined location within the packet as defined by the standard in use (for example, the IP standard).

Once the destination address is determined the router will check to see if the address is within its own network. If the address is within its own network the router will then send the packet down to the data link layer (conceptually speaking that is) which will add headers as I described in my previous article (link previous article to my OSI Layer 2 article) and will send the packet to its destination. If the address is not within the router's own network, the router will look up the address in a routing table. If the address is found within this routing table the router will read the corresponding destination network from the table and send the packet down to the data link layer and on to that destination network. If the address is not found in this routing table the packet will be sent for error handling. This is one source of errors which can be seen in data transmission across networks, and is an excellent example of why error checking and handling is required.

Encapsulation

When a router sends a packet down to the data link layer which then adds headers before transmitting the packet to its next point, this is an example of encapsulation for the data link layer.
Like the data link layer, the network layer is also responsible for encapsulating data it receives from the layer above it. In this case it would be from the data received from layer 4, the transport layer. Actually, every layer is responsible for encapsulating data it receives from the layer above it. Even the seventh and last layer, the application layer, because an application encapsulates data it receives from users.

Fragmentation

When the network layer sends data down to the data link layer it can sometimes run into trouble. That is, depending on what type of data link layer technology is in use the data may be too large. This requires the network layer have the ability to split the data up into smaller chunks which can each be sent to the data link layer in turn. This process is known as fragmentation.

Error handling

Error handling is an important aspect of the network layer. As I mentioned earlier, one source of errors is when routers do not find the destination address in their routing table. In that case, the router needs to generate a destination unreachable error. Another possible source of errors is the TTL (time to live) value of the packet. If the network layer determines that the TTL has reached a zero value, a time exceeded error is generated. Both the destination unreachable error and the time exceeded error messages conform to specific standards as defined in the Internet Control Message Protocol (ICMP).

Fragmentation can also cause errors. If the fragmentation process takes too long, the device can throw an ICMP time exceeded error.

Congestion control

Another responsibility of the network layer is congestion control. As I am sure you know, any given network device has an upper limit as to the amount of throughput the device can handle. This upper limit is always creeping upward but there are still times when there is just too much data for the device to handle. This is the motivation for congestion control.

There are many theories for how to best accomplish this, most of which are quite complicated and beyond the scope of this article. The basic idea of all of these methods is that you want to make the data senders compete for their messages to be the ones to get accepted into the throughput. The congested device wants to do this in a way that lowers the overall amount of data it is receiving. This can be accomplished by 'punishing' the senders which are sending the most data which causes the senders to 'slow' their sending activity to avoid the punishment and thereby reducing the amount of data seen by the congested device (which at this point is no longer congested).

Author's rant: The congestion control algorithms are quite complex for various reasons. Firstly, the mathematics involved is intense. So, for all of you who have ever wondered why people study mathematics in university and what job they could possibly get with that education.... this is an important one, and one that pays well with networking companies such as CISCO and Nortel. Secondly, after you have determined the proper mathematics to accomplish this task, how can it be implemented in a efficient and fast manner? This is the domain of engineers, who need to understand the mathematics, possible software implementation strategies, possible hardware implementation strategies, and design methodologies. Many people, including those who work in the tech industry, do not really understand what these, and other, professions bring to the table: they should. It is important.

In my next article I will discuss the fourth layer of the OSI reference model; the transport layer. Until then, as always, if you have any questions about this or any previous article please feel free to send me an email; I will do my best to answer any and all questions.

OSI Reference Model: Layer 4 Hardware

2008-08-12T04:42:00.000-07:00

The previous articles in the series have discussed the first three layers of the OSI Reference Model. We will now discuss the fourth layer; the Transport layer.

The Transport layer provides the functionality to transfer data from one end point to another across a network. The Transport layer is responsible for flow control and error recovery. The upper layers of the OSI Reference Model see the Transport Layers as a reliable, network independent, end-to-end service. An end-to-end service within the transport layer is classified in one of five different levels of service; Transport Protocol (TP) class 0 through TP class 5.

TP class 0

TP class 0 is the most basic of the five classification levels. Services classified at this level perform segmentation and reassembly.

TP class 1

TP class 1 services perform all of the functions of those services classified at TP class 0 as well as error recovery. A service at this level will retransmit data units if they were not received by the intended recipient.

TP class 2

TP class 2 services perform all of the functions of those services classified at TP class 1 as well as multiplexing and demultiplexing, more on this below.

TP class 3

TP class 3 services perform all of the functions of those services classified at TP class 2 as well as sequencing of the data units to be sent.

TP class 4

TP class 4 services perform all of the functions of those services classified at TP class 3 as well as the ability to provide its services over either a connection oriented or connectionless network. This class of Transport Protocols is the most common and is very similar to the Transmission Control Protocol (TCP) of the Internet Protocol (IP) suite.

I say that TP class 4 is very similar to TCP because there are some key differences. TP class 4 uses 10 data types while TCP uses only one. This means that TCP is simpler but also means that it must contain many headers. TP class 4, while more complicated, can contain one quarter of the headers that TCP contains which obviously reduces a lot of overhead.

Connection oriented networks

Connection oriented networks are like your telephone. A connection is made before data is sent and is maintained throughout the entire process of sending data. With this type of network, routing information only needs to be sent while setting up the connection and not during data transmission. This reduces a lot of overhead which improves communication speed. This type of communication is also very good for applications, like voice or video communications, where the order of the data received is especially important.

Connectionless networks

Connectionless networks are the opposite of connection oriented networks, in that they do not set up a connection prior to sending data. Nor do they maintain any connection between two end points. This requires that routing information is sent with each packet, which therefore increases the communication overhead.

Keep in mind that just because data is being sent in packets does not mean that it is a connectionless network; virtual circuits are an example of a connection oriented network that use packets.

Since, in my previous articles, I have already covered aspects of error detection and recovery and since this article is focused on hardware I am going to give a basic introduction to a widely known (yet poorly understood) aspect of the Transport Layer; multiplexing and demultiplexing.

Multiplexing

Multiplexing (or muxing as it is often referred to) is one of those words that people often hear while not really understanding what it means. Many people may know that muxing is the process of combining two or more signals into one signal, but how exactly is that done? Well, there are multiple ways in which this can be done. Digital signals can be muxed in one of two ways, time-division multiplexing (TDM) and frequency division multiplexing (FDM). Optical signals use a method called wavelength-division multiplexing, although this is the same thing as FDM (wavelengths of course being inversely proportional to frequency).

To demonstrate how muxing works, let's take a simple case of TDM. In this example let's assume a two signal input. A two input muxing device will require three inputs; one for each of the signals and one for the control signal. A two input muxing device will also have one output. This device will alternate between the two input signals putting the resulting signal onto its output.

Figure 1: Logic gate schematic of a two input mux. Courtesy of www.cs.uiowa.edu Figure 1, above, shows a two input mux. The two signals are represented as d0 and d1 while the control signal is represented as c. The output, which is a function of the two inputs, is represented as f. The symbols in this figure are standard symbols for representing logic gates. Figure 2, shows the meaning of these three gates.

Figure 2: Basic logic gates. Courtesy of www.cs.uiowa.edu

The mux works by receiving a digital signal on the c input. This c signal goes directly to one input of the 1 'AND' gate, and to the 'NOT' gate. The 'NOT' gate inverts the signal and then sends it to one input of the 2 'AND' gate. The outputs of the 'AND' gates will only be high when the control signal and the input signal (d0 or d1) are high. Since the control signal is sent through a 'NOT' gate prior to reaching the 2 'AND' gate only one of the two 'AND' gates will see a high control signal at any one instant in time. This process means that f will alternate between being equal to d0 and then to d1 at the frequency of c.

Now you might be thinking "that's great, but who cares about getting half the signal". Well, that does not necessarily have to be the case. If the frequency of the control signal is at least twice the frequency of input signals, then the output f will contain enough information about both d0 and d1 that a demuxer will be able to reconstruct the original input signals. This is the core idea of the Nyquist-Shannon sampling theorem.

Looking at the logic gates in Figures 1 and 2 those of you with programming or scripting experience will recognize these logic functions as common tools in a programmer’s repertoire. Keep in mind that while these functions are found in software programs, I am strictly talking about hardware functions which are carried out with a series of transistors, acting as switches, arranges in clever ways to achieve these logic functions.

Demultiplexing

A demuxer is basically the opposite of a muxer. A demuxer will have one input signal, and in the case described above will have two output signals. A demuxer, of course, also has a control signal although with demuxers it is often called the addressing signals. This control signal is called an address signal because the demuxing circuit can also be used to simply choose which output pin to put the input signal on to.

In my next article I will discuss the fifth layer of the OSI Reference Model. Until then, and as always, if you have any questions about this or any other article of mine, do not hesitate to send me an email; I will do my best to get back to you.

Removing The Last Exchange 2003 Server From Exchange 2007 (Part 1)

2008-08-07T00:55:00.001-07:00

The steps required in order to remove the last Exchange 2003 server from an organization that has been migrated to Exchange 2007.

In a previous article here on MSExchange.org, I covered the process required to correctly remove the first Exchange 2003 server that had been installed into an administrative group. There were several steps required to achieve this without breaking some functionality. A similar process needs to be undertaken in order to remove the last Exchange 2003 server from an organization that has been migrated to Exchange 2007. Tucked away in the release notes of the Release To Manufacturing (RTM) version of Exchange 2007, Microsoft detailed this process. That process has now made its way to the main Exchange 2007 documentation. In this article we’ll look at this process and go through the items in it to see how it shapes up, including plenty of screen shots as usual here on MSExchange.org.

As is normally the case with Exchange, there are many different possible configurations available to demonstrate and so it’s always a challenge to pick a configuration which appeals to a wide audience but at the same time isn’t overly complicated. Therefore, for this article I’ve taken the approach where a single Exchange 2003 server is coexisting with a single Exchange 2007 server which will obviously fit many situations. For larger systems, the same principles can be applied.

It goes without saying that the first thing you need to make sure of is that all user mailboxes have been migrated to the Exchange 2007 server. I won’t be covering the process of doing this within this article as I’ve already done that in a separate article here on MSExchange.org. However, personally I’m a big fan of ensuring that the new Exchange 2007 server is handling the production load as soon as possible. That doesn’t just include migrating the user mailboxes to it as there are other important roles the Exchange 2007 server can perform from the moment it’s made a production server. The first and most obvious is the handling of Internet email and so the remainder of this article will cover setting this up before we move on to other tasks in the next part. If you’ve already configured Internet email to be routed via Exchange 2007 you can skip this article, but I thought it useful to detail this process for completeness.

Internet Email

Most Exchange 2003 systems have a simple SMTP Connector configured to handle Internet email and so that’s the example I’ll be using within this article. A typical example is an SMTP Connector that simply has an address space of * and a cost of 1, meaning that the connector handles all SMTP email for any external SMTP domain. As a result of the coexistence between Exchange 2003 and Exchange 2007, it’s possible to see the SMTP Connector within the Exchange Management Console running on the Exchange 2007 server, where it appears as a Send Connector as shown in Figure 1.

Figure 1: Exchange 2003 SMTP Connector

Logic may dictate that, since an SMTP Connector can have multiple source bridgehead servers in Exchange 2003, the Exchange 2007 server could be added as an additional bridgehead server in order to make the transition seamless. However, it’s not possible to add the Exchange 2007 server as an additional source bridgehead server via the Exchange System Manager or Exchange Management Console snap-ins as the Exchange 2003 and Exchange 2007 servers are in different routing groups. If you do try from the Exchange Management Console, you will get an error such as the one shown in Figure 2.

Figure 2: Exchange 2007 as Additional Bridgehead Server Error

Therefore, the correct way to ensure that all Internet email is handled by Exchange 2007 is simply to create a new Send Connector in Exchange 2007.

New Send Connector

Since the existing SMTP Connector has a cost of 1, it makes sense to raise this cost to, say, 10 before creating the new Send Connector. That way, the new Send Connector can be created with a cost of 1 meaning that it will be used in preference to the SMTP Connector. Of course, the alternative is to simply delete the SMTP Connector from Exchange System Manager once you’ve created the new Send Connector, thus ensuring that the only path available is via Exchange 2007. However, it’s always nice to leave old configurations in place until you are sure that the new configuration is working. Here are the steps required to create the new Send Connector:

In the Exchange Management Console, expand Organization Configuration, click Hub Transport and then select the Send Connectors tab.
Either right-click Hub Transport and choose New Send Connector… from the context menu, or choose the same option from the action pane.
The New SMTP Send Connector wizard appears and consists of the following screens. I’ll briefly cover each screen and what you should enter.

- First up is the Introduction screen. In the Name field, give this connector a suitable name such as Internet Email. It may help to distinguish this name from the name of any existing SMTP Connectors hosted on Exchange 2003. In the drop-down list used to configure the intended use of the connector, choose Internet. The completed screen is shown in Figure 3.

Figure 3: New SMTP Send Connector Introduction Screen

Next is the Address Space screen where you simply need to click the Add button and in the resulting Add Address Space window, type the domain name to which you want to deliver Internet email. The most common domain name typed here is simply *, which represents all external domain names from your Exchange organization. Make sure the cost is lower than the cost of the Exchange 2003 SMTP Connector.
The next screen is the Network Settings screen where you configure the Send Connector to either use DNS or a smart host to send Internet email. Here you’ll likely replicate the configuration of the Exchange 2003 SMTP Connector. In Figure 4 below I’ve used the IP address of a smart host which therefore assumes that the Exchange 2007 Edge Transport server role hasn’t been deployed. Don’t forget to ensure that your smart host allows connections from the Exchange 2007 server.

Figure 4: New SMTP Send Connector Network Settings Screen

If you choose to route through a smart host the next screen that will be presented to you is the Configure smart host authentication settings screen. This allows you to specify any authentication options that your smart host may require such as basic or Exchange server authentication. In my case, no authentication is required so I just select None and progress to the next screen.
Next the Source Server screen is presented as shown in Figure 5. Note that the Exchange 2007 server name is already populated in the list. In situations where you have more than one Hub Transport server, you can add additional servers via the Add button. The Source Server screen is shown in Figure 5.

Figure 5: New SMTP Send Connector Source Server Screen

The penultimate screen is the New Connector screen that allows you to review your settings. Clicking the New button then proceeds to create the new SMTP Send Connector, the result of which is then displayed at the Completion screen. At this point, you’ve now created a new SMTP Send Connector to handle Internet email.

As I mentioned earlier, this connector will handle ALL external email for domains other than those configured on your local Exchange 2007 server. This may not always be desirable. For example, if you have a private network link to a partner organization, you can create an additional SMTP Send Connector and specify the partner SMTP domain name in the address space field. This would be a more explicit match than the general * domain and therefore you can control message flow to this domain. In the Network Settings screen of this connector, you’d likely specify a different IP address for a different smart host.

Removing The Last Exchange 2003 Server From Exchange 2007 (Part 2)

2008-08-07T00:48:00.000-07:00

Configuring inbound Internet as well as moving the public folders and Offline Address Book generation to the Exchange 2007 server.

Introduction

In part one of this four-part article, we started the process of allowing the Exchange 2003 server to be removed by creating a new Send Connector on the Exchange 2007 server so that all outbound Internet email can be processed by Exchange 2007 rather than Exchange 2003. In part two of this article, we’ll look at some basic inbound Internet email considerations and then move swiftly on to the process of moving public folders to the new Exchange 2007 server, as well as ensuring that the Offline Address Book generation server is specified as the Exchange 2007 server.

Inbound Internet Email

The steps listed in part one of this article take care of outbound Internet email from your Exchange 2007 organization. For inbound Internet email, I’m making the assumption in the lab environment that the Exchange 2007 Edge Server role hasn’t been deployed and that you are using a 3^rd party SMTP hygiene product to filter email before it is sent to your users. You’d obviously need to ensure that any smart host that processes inbound Internet email for your Exchange 2007 organization is configured to send these messages to the Exchange 2007 server and not the Exchange 2003 server. Specifically, the smart host sends messages to the Hub Transport server role. Be aware, though, that the default SMTP Receive Connector configured on an Exchange 2007 Hub Transport server does not allow anonymous connections by default which is required to accept Internet email in the case where no Edge Transport server is deployed. Note that the process is slightly different when the Edge Transport server role is used.

To modify the properties of your default receive connector on your Hub Transport server, do the following:

Run the Exchange Management Console, navigate to Server Configuration and then click the Hub Transport object. In the result pane, there is only the Receive Connectors tab displayed which shows a list of receive connectors configured on this Hub Transport server.
Bring up the properties of the default Receive Connector, in my case called Default E2K7, and go to the Permission Groups tab.
On the Permission Groups tab, select the Anonymous users check box and then click OK to close the window and accept the configuration. This configuration is shown in Figure 6.

Figure 6: Default Receive Connector Anonymous Permissions

Public Folders

Although public folders are de-emphasized in Exchange 2007, they are still very much part of the product and there’s a fair chance that you are still using them at the moment within your Exchange infrastructure. Obviously you are going to need to migrate the data contained within the public folders over to Exchange 2007 and effectively the process is the same as if you were migrating the public folders to a different Exchange 2003 server.

Moving public folders is essentially a two-step process. The first step is to ensure that a replica of the public folder exists on the Exchange 2007 server whilst the second step is to remove the replica from the Exchange 2003 server. Fortunately, Microsoft has made the whole process really easy with two main options for us to use. First, there’s the Move All Replicas option in Exchange 2003 Service Pack 2, and second there’s the MoveAllReplicas.ps1 script provided with Exchange 2007. Let’s look at both options.

Exchange 2003 Service Pack 2 introduced a rather handy menu option that you will find on the properties of the Exchange 2003 public folder store. In Exchange System Manager running on your Exchange 2003 server, navigate down the hierarchy and locate the Exchange 2003 server. Expanding the server object, continue to navigate down underneath the relevant storage group object until you find the public folder database. Here, you can right-click the public folder database and you’ll see the Move All Replicas option as shown in Figure 7 below.

Figure 7: Move All Replicas Menu Option

This menu option will automatically move all public folders that are hosted on this public folder database to an alternative public folder database of your choice. Before we do that though, let’s confirm how many public folders we need to move. To do this, continue to expand the public folder database object in Exchange System Manager until you see the Public Folder Instances object. Selecting the Public Folder Instances object will show the instances of public folders that occur on this particular public folder database and you can see from Figure 8 that we have a small number of public folders to deal with. This includes both user public folders and additionally system public folders such as the Schedule+ Free/Busy folder.

Figure 8: Public Folder Instances

The goal with the migration of the public folders to the Exchange 2007 server is to end up with a Public Folder Instances object on Exchange 2003 that shows zero entries in the list, which can be accomplished via the Move All Replicas menu option for this example. However, the main thing to remember with regard to public folder replication and re-homing is patience, particularly in large environments. It could take several days to complete the replication and re-homing process in very large environments as there are many different factors to be taken into consideration. Later in this article we’ll look at removing the public folder database from the Exchange 2003 server. Just remember, do not proceed with the attempted removal of the Exchange 2003 public folder database or the actual server unless there are zero entries in the Public Folder Instances tab.

The Move All Replicas option itself is simple enough to follow. Once you choose the option, a Move All Replicas window will appear asking you to select the server to which you want the public folders moved. This is shown in Figure 9 where you can see that the server E2K7 is already highlighted since that’s the only other server running a public folder database.

Figure 9: Moving All Public Folder Replicas

Once you’ve chosen the relevant server and clicked OK, a warning prompt appears telling you that the process may take some time and to check the Public Folder Instances tab to confirm the process has been completed. Once you click OK to this warning, another window titled Propagating properties to subfolders will appear and will show the progress as the settings are applied. Once this window disappears, you now need to wait for the move to occur in the background. As I’ve said earlier, you need to wait until the Public Folder Instances is empty as shown below.

Figure 10: No More Public Folder Instances

The MoveAllReplicas script provided with Exchange 2007 is even easier to use. You will find this script in the \Program Files\Microsoft\Exchange Server\Scripts folder. From the Exchange 2007 server, run the Exchange Management Shell and then execute the following script:

MoveAllReplicas.ps1 –Server E2K3 –NewServer E2K7

As you can see there are only two parameters, namely Server, the source server, and NewServer, the target server. Once run successfully, the script doesn’t echo anything to the screen so once again, check the Public Folder Instances object on the Exchange 2003 server to confirm that no replicas are left on the Exchange 2003 server.

Offline Address Book

One of the components that you should have updated when removing the first Exchange 2003 server installed into an administrative group was the server responsible for generating the Offline Address List server. This is still a requirement when removing the last Exchange 2003 server from an Exchange 2007 environment since the server responsible for generating the Offline Address Book (note the name change for Exchange 2007) is likely to be the Exchange 2003 server. Here’s the process to do this using the Exchange Management Console:

Run the Exchange Management Console.
Select Organization Configuration and then select the Mailbox object. In the list of tabs displayed, click the Offline Address Book tab and you should see a screen similar to that shown in Figure 11. Note that the Generation Server column references the Exchange 2003 server name.

Figure 11: Offline Address Book Entry in Exchange Management Console

Right-click the entry for the Default Offline Address List and choose the Move option from the context menu. This will bring up the Move Offline Address Book wizard window which consists of a single configuration screen.
On the opening screen, click the Browse button and in the resulting Select Mailbox Server window, locate and choose the Exchange 2007 mailbox server.
Back at the opening screen, ensure that the new Exchange 2007 server name is referenced in the Offline address book generation server field as shown in Figure 12.

Figure 12: Preparing to Move the OAB

Once you are happy that the correct configuration has been selected, click the Move button. The Completion screen should then reveal that the move has been successful.

We’ll look at using the Exchange Management Shell to move the Offline Address Book in the next part of this article.

Removing The Last Exchange 2003 Server From Exchange 2007 (Part 3)

2008-08-07T00:41:00.000-07:00

Moving the Offline Address Book using the Exchange Management Shell, removing the databases from Exchange 2003 and removing the Routing Group Connectors.

Introduction

So far in parts one and two of this four-part article we’ve detailed the initial steps required to prepare for the removal of an Exchange 2003 server that is coexisting with an Exchange 2007 server. This has included the re-routing of Internet email, the moving of public folders and also the moving of the Offline Address Book via the Exchange Management Console. Before we move away from the Offline Address Book topic, let’s complete the overall picture by covering how you can move the Offline Address Book via the Exchange Management Shell as some administrators prefer this method.

Moving OAB via Management Shell

If you prefer to use the Exchange Management Shell to move the Offline Address Book, the cmdlet to use is the Move-OfflineAddressBook cmdlet. First you can run the Get-OfflineAddressBook cmdlet to list all OABs and if you pipe the results to the format-list cmdlet you get all the information you need about the various OABs. Take Figure 13 as an example, where you can see that the results of the Get-OfflineAddressBook | fl cmdlet shows that we have just a single OAB called Default Off line Address List as expected.

Figure 13: Offline Address Book List

To move the OAB generation server, note that it’s the Server parameter at the top of the listing in Figure 13 that we’re interested in and not the originating server parameter you see towards the bottom. Our full cmdlet is therefore:

Move-OfflineAddressBook “Default Offline Address List” –Server E2K7

The results of running this cmdlet are shown in Figure 14 where you can see that the only interaction we get is an “are you sure?” prompt and a friendly warning about a possible entire download of the OAB for all users.

Figure 14: Moving the Offline Address Book

Remove Mailbox and Public Folder Databases

Now it’s time to go back to public folders. Once you’ve confirmed that there are no longer any public folder replicas on the Exchange 2003 server, you can then remove the public folder database. If you try and do this with instances still on the database, you’ll receive the following error:

Figure 15: Unable to Remove Public Store

To remove the public folder database, right-click it in Exchange System Manager and choose Delete from the context menu. You will be prompted with a warning that informs you the public store is performing various roles and that these roles must be moved to an alternate public folder store. This warning is shown in Figure 16 below.

Figure 16: Public Store Roles

As you can see there is no choice but to select OK. Once you do this, you’ll be presented with another window that allows you to choose your alternate public store as you can see from Figure 17. In my example scenario, there is only one other server to choose from, the Exchange 2007 server, and therefore this has been selected.

Figure 17: Selecting Alternate Public Store

You are then presented with a “Are you sure?” prompt before your public store is deleted from the Exchange 2003 server. A final prompt is then displayed informing you that although the store has been deleted from the Exchange 2003 configuration, the physical database files still reside on the server so it’s obviously a good idea to clean these up especially if the Exchange 2003 server won’t be decommissioned straight away.

Whilst you’re in the mood for database removal, and assuming you have actually moved all users from the Exchange 2003 server to the Exchange 2007 server, you can now remove the mailbox database from the Exchange 2003 server in the same manner if you want to. Of course, Exchange 2003 protects you in the scenario where mailboxes still exist on the server since when you try to delete the mailbox store you will receive the following error.

Figure 18: Unable to Remove Mailbox Store

Assuming that you have no mailboxes left on this mailbox store, you will receive the following warning when you attempt to delete it.

Figure 19: Mailbox Store Removal Warning

Assuming you are comfortable with the fact you have previously migrated the system folders across, proceed with the mailbox store removal. As per the public store removal, you are then presented with an “Are you sure?” prompt followed by the warning that the physical database files need to be manually removed from the server.

Routing Group Connectors

Now here’s a potentially scary part of the process. You’ll remember that when you install your Exchange 2007 servers into an existing Exchange 2003 organization, a new administrative group is created that contains all Exchange 2007 servers. This administrative group is called

Exchange Administrative Group (FYDIBOHF23SPDLT). Furthermore, you’ll also remember that when the first Exchange 2007 Hub Transport server is installed into an existing Exchange 2003 organization, a new two-way Routing Group Connector is created to allow mail flow between the Exchange 2003 and Exchange 2007 servers. These are highlighted in Figure 20 below where they are shown as seen from within the Exchange System Manager.

Figure 20: Two-Way Routing Group Connectors

Well, it’s now time to remove these Routing Group Connectors which you can do either with the legacy Exchange 2003 Exchange System Manager or, of course, the Exchange Management Shell. Since there are no users or public folder databases left on Exchange 2003, there is no need for messages to flow between the two servers. Let’s look at both methods so that you can pick your favorite.

In Exchange System Manager on your Exchange 2003 server, navigate to either one of the Connectors containers and select the Routing Group Connectors as shown above in Figure 20. It doesn’t really matter which side of the Routing Group Connector you delete first. Right-click the Routing Group Connector and choose Delete from the context menu. You will be presented with an “Are you sure?” prompt as normal after which the connector should be deleted. Repeat this process for the other side of the Routing Group Connector.

To do the same thing in the Exchange Management Shell, you need to use the Remove-RoutingGroupConnector cmdlet. There aren’t many parameters to add to this cmdlet but since the –Identity parameter includes the administrative group name as well as the routing group name the cmdlet does get quite long as you can see from the example below. Having said this, in my lab environment I could simply specify the identity as the names of the Routing Group Connectors without the administrative and routing group names and they were successfully deleted. However, I recommend that you use the full name to make sure you are targeting the correct Routing Group Connector. Since there are two sides to delete, the cmdlet must be run twice to specify each side of the Routing Group Connector to delete.

Remove-RoutingGroupConnector –Identity “First Administrative Group\First Routing Group\E2K3-E2K7”

Remove-RoutingGroupConnector –Identity “Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR\E2K7-E2K3”

Removing The Last Exchange 2003 Server From Exchange 2007 (Part 4)

2008-08-07T00:30:00.000-07:00

The final steps required in order to remove the last Exchange 2003 server from an organization that has been migrated to Exchange 2007.

Introduction

Since part one of this four-part article we’ve re-routed Internet email, moved the public folders, moved the Offline Address Book, removed the mailbox and public folder stores from the Exchange 2003 server and removed the Routing Group Connectors created during the installation of Exchange 2007. As you can see, there is quite a list of things to do before we can get around to removing Exchange 2003 and there are still a few more to go. In this last part of this article we’re going to look at what we need to do with our recipient policies, the public folder hierarchy and lastly the Recipient Update Services.

Once all these have been dealt with, we can then think about removing the Exchange 2003 software from the server.

Prepare Your Recipient Policies

One important topic to cover is preparing the recipient policies prior to removal of Exchange 2003. In Exchange 2003, a recipient policy can control email address generation as well as Mailbox Manager settings. For example, when creating a new recipient policy in Exchange 2003 you are presented with the window shown in Figure 21 where you can see the option to create E-Mail Addresses or Mailbox Manager Settings.

Figure 21: New Recipient Policy

Therefore, policies that have both email addresses and Mailbox Manager settings will have the corresponding tabs present when you view the properties of the recipient policy as shown in Figure 22. Recipient policies may also only have either the E-Mail Addresses tab or the Mailbox Manager Settings tab.

Figure 22: Recipient Policy With Both Settings

The problem is that later, you will upgrade your recipient policies via an Exchange Management Shell cmdlet. Policies with Mailbox Manager settings on them cannot be upgraded and thus the Mailbox Manager portion of the policy must be removed. How you prepare your recipient policies depends on which tabs are present within the policies. If there is only a Mailbox Manager Settings tab present, this policy should be deleted completely. To do this right-click the policy in Exchange System Manager and choose Delete from the context menu.

Move Public Folder Hierarchy

Previously within part two of this article we moved the public folder contents from the Exchange 2003 server to the Exchange 2007 server to the point where we were able to remove the public folder store from the Exchange 2003 server. However, we’re not finished yet with public folders since the hierarchy still exists within the Exchange 2003 administrative group as you can see from Figure 23.

If there are both Mailbox Manager Settings and E-Mail Addresses tabs visible, then right-click the policy and choose the Change property pages… option from the context menu. You will then be presented with the window shown in Figure 21 although this time both check boxes will be selected. You need to clear the Mailbox Manager Settings check box to remove this from the policy.

The important thing to remember is that only email address policies should remain. What happens to the Mailbox Manager settings? You’ll need to create equivalent Messaging Records Management policies and I’ve covered this subject here on MSExchange.org

Figure 23: Public Folder Hierarchy in Exchange 2003 Administrative Group

Moving the public folder hierarchy is simply a question of dragging and dropping it into the new administrative group created during the installation of Exchange 2007. However, before it can be dragged and dropped a new Folders container must be created within the Exchange 2007 administrative group. This is done from within the Exchange System Manager on your Exchange 2003 server. Yes, that’s right – you will be making a change to the Exchange 2007 administrative group using the Exchange 2003 Exchange System Manager. This can be achieved by right-clicking the Exchange 2007 administrative group called Exchange Administrative Group (FYDIBOHF23SPDLT). From the resulting context menu, choose New and then choose Public Folders Container. The result will be a new Folders container under the Exchange 2007 administrative group. You can then simply drag the Public Folders object from the Exchange 2003 administrative group to the Exchange 2007 administrative group, the result of which is shown in Figure 24.

Figure 24: Public Folder Hierarchy Moved

That may appear to be a simplistic approach to moving the public folder hierarchy but that’s the recommendation from Microsoft and I’ve used it successfully in Exchange 2003 to Exchange 2007 migration projects.

Remove Recipient Update Services

It’s now time to remove the Recipient Update Service (RUS) objects that are present in Exchange 2003 as they are no longer used in Exchange 2007. You will find the RUS objects in the Exchange System Manager under the Recipients node.

One type of RUS, the Domain RUS, can be deleted via Exchange System Manager. The other type of RUS, the Enterprise RUS, cannot and we’ll cover how that’s done in just a minute. In Figure 25, you can see the two RUS objects that are present and it should be obvious that the one with Enterprise Configuration in its name is the Enterprise RUS.

Figure 25: Exchange 2003 Recipient Update Services

First, let’s look at deleting the Domain RUS in Exchange System Manager. Simply right-click the Domain RUS and choose Delete from the context menu. You will of course be presented with an “Are you sure?” prompt. That’s all there is to it.

To delete the Enterprise RUS, however, requires the use of ADSIEdit since you’ll notice that there is no delete option if you right-click this RUS in Exchange System Manager. ADSIEdit can be obtained by installing the Windows 2003 Support Tools from the Windows 2003 CD. With ADSIEdit connected to the configuration naming context, drill down the tree in the following order:

Configuration / Services / Microsoft Exchange / / Address Lists Container / Recipient Update Services

You should see a screen similar to the one shown in Figure 26. All you need to do is to right-click the Enterprise RUS object, which is highlighted in Figure 26, and select Delete from the context menu. The RUS object will be deleted with no questions asked. As ever, be careful when using ADSIEdit to delete objects as you can do some damage if you delete the wrong objects.

Figure 26: Removing the Enterprise RUS With ADSIEdit

Remove Exchange

At this time you’re now in a position to remove the Exchange software from the server. To do this just go to Control Panel and then choose the Add/Remove Programs option. Highlight the Microsoft Exchange entry and click the Change/Remove button. You will then be presented with the Exchange installation wizard and on the Component Selection screen you will be in a position to change the Action setting of the parent Microsoft Exchange object to Remove. This will then change the Action setting of the other installed items to Remove as shown in Figure 27.

Figure 27: Removing Exchange 2003

You can then proceed to follow the remaining wizard screens to remove Exchange. Note, though, that you’ll more than likely be prompted for the Exchange installation CD during the un-installation process so make sure you have that handy before you start, or at least a path to the Exchange 2003 setup files somewhere on your network.

I’d like to finish this article by highlighting a warning that Microsoft makes about deleting the legacy administrative groups that belonged to Exchange 2000 or Exchange 2003. You should not delete any of these administrative groups if they held mailboxes at any previous stage. Simply leave the administrative groups as they are and forget all about them.

Re-installing the Cluster nodes in an Exchange 2007 CCR-based Mailbox Server Setup (Part 2)

2008-08-07T00:19:00.000-07:00

In the second part of this series we will now install the passive mailbox role.

Introduction

In the previous article, we uninstall ed the passive clustered mailbox role from the first CCR node, evicted the node from the Windows cluster and then re-added the node to the Windows cluster after the operating system had been re-installed and configured accordingly.

In this part two of this articles series, we can move on where we left off in part one by installing the passive mailbox role. To do so, launch Exchange 2007 Setup.exe, and then click Install Microsoft Exchange Server 2007 SP1 (Figure 2.1).

Note:
The clustered mailbox server in the lab I’m using for the purpose of this article is running Exchange 2007 SP1, which is why I use the Exchange Server 2007 SP1 binaries to re-install the passive Mailbox role. If you’re CMS haven’t yet been upgraded to Exchange 2007 SP1, it’s important you use the Exchange 2007 RTM binaries to re-install the passive Mailbox role.

Figure 2.1: Exchange Server 2007 SP1 splash screen

On Introduction page, click Next > accept the License Agreement and click Next. Decide whether or not you want to enable error reporting, and then click Next once again.

On the Exchange 2007 Setup Installation Type page, select Custom Exchange Server Installation and click Next (Figure 2.2).

Figure 2.2: Selecting a Custom Exchange Server Installation

Now tick Passive Clustered Mailbox Role. If you installed the Exchange 2007 binaries at another location than the default, this is also the page on which you change the installation path (Figure 2.3). Click Next.

Figure 2.3: Selecting Passive Clustered Mailbox Role and specifying the Installation path

The readiness checks will now be performed. This will normally complete without any issues or errors, but if you like me forgot to remove the database and log files from the Database or Log file LUNs, you’ll receive an error similar to the one shown in Figure 2.4.

Figure 2.4: Readiness Check error as databases are present on the database LUN

When removed, you should see a Readiness Checks page like the one in Figure x (of course without the 32-bit version warning). Click Install.

Figure 2.5: Readiness Checks Completed Successfully

The installation process will now begin and after a few minutes you should get a completion page as shown below (Figure 2.6).

Figure 2.6: Installation of Passive Clustered Mailbox Role installed successfully

Now that the Exchange 2007 SP1 binaries have been installed, we must reboot the node before continuing with the next steps.

Next step is to reseed the storage group copies, so that the CCR node gets up to date replicas of each the active databases. This can be done using the Exchange Management Shell and when speaking Exchange 2007 SP1 the Exchange Management Console (EMC) UI. In this article, we’ll use the EMC UI, so launch the EMC. In the EMC, select the clustered mailbox server under the Server Configuration work center. As we can see in Figure 2.7 below, the copy status is currently in a failed mode, which is expected.

Figure 2.7: Copy status is currently in a Failed state

If we open the Property page for one of the storage groups and click on the Cluster Continuous Replication tab, we can also see that no logs have been copied to the newly installed CCR node.

Figure 2.8: No logs have been copied to the new CCR node

To seed the passive node, select a storage group and click Update Storage Group Copy in the Action pane (Figure 2.9).

Figure 2.9: Update Storage Group Copy

On the Update Storage Group Copy Introduction page, click Next (Figure 2.10).

Figure 2.10: Update Storage Group Copy Wizard

On the Summary page, click Update (Figure 2.11).

Figure 2.11: Update Storage Group Copy page

If you receive the warning shown in Figure 2.12, click Yes.

Figure 2.12: Checkpoint File Warning

After a while (depending on the size of the databases) you’ll be taken to the Completion page (Figure 2.13), where you simply click Finish.

Figure 2.13: Completion page

The storage group will now be in a healthy state (Figure 2.14) and any log files will have been copied to the passive node (Figure 2.15)

Figure 2.14: Healthy Copy Status

Figure 2.15: Log file copy dates updated

You must run the Update Storage Group Copy wizard for any existing storage groups.

Re-installing the Second CCR Node

Time has come to re-install the second CCR node. Since the steps are identical to the ones we went through in order to re-install the first CCR node, I won’t repeat them. Just go back to part one of this articles series and follow each step until you end up here again.

Managing Unified Messaging Auto Attendant (Part 1)

2008-08-07T00:13:00.000-07:00

How to record personalized voice prompts and create a UM Auto Attendant in Exchange Server 2007.

Introduction

Exchange Server 2007 introduced a new role called Unified Messaging (UM) which allows integration between the messaging system and telephone system. By using the UM role we can now receive fax, OVA (Outlook Voice Access), voice mails, etc. All the information like missed calls, voice mails, etc will now be stored in the mailbox store.

With these new capabilities Exchange Server 2007 is able to receive calls from internal or external sources and work on this incoming call playing voice prompts and recognizing voice commands or telephone keyboard (touchtone) input. This feature is known as Auto Attendant and we will see how, through Auto Attendant, we can use an Automatic Speech Recognition (ASR) interface or a touchtone. We can provide the company available resources such as departments, business hours, search an employee name in a specific address list and then redirect them to the right resource without using human resources to give them this information.

By default the auto attendant feature has a set of voice prompts that are said during the incoming calls however we can configure special greetings for Business and non-business hours, and informational messages; we can also define holiday prompts, allow users to transfer to an operator, place a call, leave a message, look up either the Global Address list, users in the same dial plan or specific Address List, create a customized menu prompt and create key mapping where the caller can say or type some information and the Auto Attendant will evaluate this information and take an action based on a set of pre-existent rules.

Note:
We will use square brackets to represent voice messages in this article []. When you see something like: [Hello World!] it is voice content.

I assume that you have configured all requirements related to Unified Messaging before creating the Auto Attendant, these requirements include: IP-PBX or VoIP gateway routing to Exchange Server or an OCS/Exchange 2007 integration; the Exchange setup has also been completed, such as: dial plan, IP gateway, hunt group, and the association of UM Server with a dial plan.

Recording the Voice Prompts to be used with UM Auto Attendant

First of all, find a person with a good voice in your company to record the greetings message. You can use any Audio Recorder that allows choosing the Audio Format, the requirements in order to record Exchange Server 2007 voice prompts are recording in WAV format and the following attributes: Linear PCM (16 bit/sample), 8 kilohertz (kHz) and .wav extension.

We are going to use the most common voice recorder: the sound recorder that comes with Windows XP and Windows 2003. In order to record the customized voice prompts follow these steps:

Click on Start, Programs, Accessories, Entertainment.
Click on Sound Recorder.
Click on the Rec button to record and start speaking at the first Custom Voice Prompt.Click on the Stop button as soon as you finish the first prompt.
Click on File menu, and then click on Properties.
Click on Convert now…
Configure the format and attributes for PCM, 8 kHz, 16 Bit, Mono (Figure 01) and click on OK.

Figure 01

Now you can save your recorded voice prompt with an appropriate name to be used in the Auto Attendant.9.Repeat these steps for each prompt that you want to record.

Now, that we know the process to record the message we can start recording some initial Greetings and Main menu prompts to customize our Auto Attendant, the following table shows the available greetings in Auto Attendant and the default example used by Exchange Server 2007. The third and fourth columns have some examples of customized prompts that can be recorded and the file name that we are going to use in this article. You can use this table to define the file names and text that will be used in your environment.

Greeting	Default example	Customized Prompts	File Name
Business hours greeting	"Welcome to the Exchange auto attendant."	[Welcome to CompanyName.]	MainAA_Greeting_business.wav
Non-business hours greeting	-	[Thank you for calling CompanyName Our regular business hours are from 09:00 AM to 6:00 PM]	MainAA_Greeting_non-business.wav
Informational announcement	-	[To continue using this Auto Attendant you must be aware of our internal security rule SEC-171]	MainAA_Greeting_informational.wav
Business hours main menu prompt	-	[You can use the following options: For the Sales Department, press 1 or just say Sales. For the Support Department, press 2 or just say Support. For information about business hours and locations, press 3 or just say business hours and locations. If you know your party’s name, just say it.]	MainAA_Greeting_mainbusiness.wav
Non-business hours main menu prompt	-	[You can use the following options: For 24x7 support, press 1 or just say support. For information about business hours and locations, press 3 or just say business hours and locations.]	MainAA_Greeting_mainNonbusiness.wav

Table 1

This table above is only to get the general idea, be aware that you can create and probably you will need more personalized voice prompts to customize your Auto Attendant deployment.

Okay, now we have our customized prompts in .wav files. Let’s put all those files in a local directory called C:\RecordedVoicePrompts in our UM Server. Our next step is to create an UM Auto Attendant pilot to validate the UM Auto Attendant and then start working on the customization of some of the features.

Creating a Unified Messaging Auto Attendant

After recording the voice prompts that will be used by our first UM Auto Attendant, we can create our first UM Auto Attendant:

Open the Exchange Management Console.
Expand Organization Configuration.
Click on Unified Messaging.
Click on the UM Auto Attendants tab.
In the Toolbox Actions click on New UM Auto Attendant…
B>New UM Auto Attendant. This wizard defines (Figure 02) the UM Auto Attendant name and extension numbers which callers will use to reach the UM Auto Attendant. We also have two options at the bottom of the wizard: the first one (Create auto attendant as enabled) is self explanatory and the second option (Create auto attendant as speech-enabled) will allow the UM Auto Attendant to receive voice commands from the callers to improve the user experience. By default a UM Auto Attendant is not created as speech-enabled, this means we can only use the touchtone to interact with the UM Auto Attendant.
Note: We have a limit of 16 extension numbers per UM Auto Attendant.

Figure 02

Completion. Final screen of the UM Auto Attendant wizard, just click on Finish. (Figure 03)

Figure 03

We can also create UM Auto Attendant using Exchange Management Shell. The cmdlet to be used is New-UMAutoAttendant, and it can be used in the following way:

New-UMAutoAttendant –Name -UMDialPlan -PilotIdentifierList

Managing Hyper-V with SystemCenter Virtual Machine Manager 2008 (Part 1)

2008-08-07T00:00:00.000-07:00

Installing and exploring System Center Virtual Machine Manager 2008 basics.

An important aspect of virtualization is the actual management: as an administrator, you want to have a single console for managing all your virtual machines and hosts. With software such as VMware’s VirtualCenter, you can manage a complete ESX environment and add a ton of extra features (such as DRS, HA, intelligent placement, templates, etc). Microsoft’s answer to the management question is System Center Virtual Machine Manager (also known as VMM).

This piece of software is your one-stop shop to all your Virtual Server 2005 R2 (and in the 2008 release) Hyper-V hosts and even your VI3 infrastructure. VMware’s VirtualCenter can be added and so ESX hosts can be managed from within VMM. Virtual Machine Manager 2008 provides most VirtualCenter Server functionality including VMotion. More complex tasks such as adding hosts to an ESX cluster must be done using VirtualCenter itself.

It is also tightly integrated with other System Center products (such as integration with System Center Operations Manager 2007) and PowerShell. A very interesting feature is Performance and Resource Optimization (or PRO). PRO is a feature of VMM which can dynamically respond to failure scenarios or poorly configured components that are identified in hardware, operating systems or applications. VMM 2008 also integrates with the new clustering support in Windows Server 2008 to allow for fault-tolerant and cluster aware virtual machines to be created. It leverages the much talked about Quick Migration technique.

In this article, we will install and explore the basics of System Center Virtual Machine Manager 2008.

Installing System Center Virtual Machine Manager 2008

System Center Virtual Machine Manager must be installed on a Windows Server 2008 x64 edition. Yes, that is right: no support for Windows 2000 or 2003 Editions!

The prerequisites for our setup:

One Windows Server 2008 x64 Edition host with Hyper-V installed (hint: it runs without problems on a recent desktop) and enough free RAM. We called it HYPERV1
An Active Directory environment (in our case using a domain controller called DC1 on our Hyper-V machine. A default installation will do fine).
A VMM virtual machine called VMM1 running on our host. Make sure it has enough RAM assigned.

What do you need?

The latest Windows Automated Installation Kit (or WAIK, downloadable from the Microsoft website).
System Center VMM 2008 (beta) downloadable from http://connect.microsoft.com and the latest VMM update for Hyper-V RC1 version. This is a public beta.
Last but not least: a Windows Server 2008 x64 edition. You can always request a trial version.

First step: installing the Windows Automated Installation Toolkit

We need to install the WAIK toolkit ourselves. Why? Because we noticed that the WAIK kit installation provided on the VMM DVD does not install correctly and throws an error during installation. Anyway, launch the startCD executable on the WAIK DVD. Click the Windows AIK setup link and install the product.

Figure 1: Launching the WAIK setup

Installing the VMM server components

After WAIK is installed, download and install System Center Virtual Machine Manager Beta version. As we expect from a Microsoft installation, this is a Next => Next => Finish installation. Click the SETUP => Server link on the right to start the server components installation.

Figure 2: Launching the VMM server setup

Once the setup wizard has launched, you can choose to use an existing (SQL Server 2005 or better) or install SQL Express. For demo purposes, we will use the express edition. We would suggest using a dedicated SQL Server 2005 in production environments.

Figure 3: Using an SQL Server Express Edition for demo purposes

Another step in the wizard lets you create a VMM library. A VMM library is a shared folder that stores all items related to a VM: ISOs, VHD files, Virtual Machine templates and answer files for sysprep. You can create a new one or use an existing library or even combine different libraries (shares). We changed the share location to c:\VMMLib. Typically, this would be an E:\ drive on a SAN volume!

Figure 4: Creating your first VMM library

You will get a final summary of your settings and the installation will begin. Note that the WAIK kit is already installed on the server.

Installing the administrator console

The administrator console is an MMC 3.0 console used as the GUI to manage your virtual infrastructure (remember, both VirtualCenter/ESX and Hyper-V!). The console enables you to work with hosts, virtual machines, library resources and reports; monitor jobs; and perform administrative tasks for Virtual Machine Manager. It can be installed on almost any recent server or workstation OS version (XP, Vista, 2003 & 2008). Back in the initial window; click the Setup => Administrator Console link in the right pane.

This is (again) a “Next->Next->Finish” installation. Note that the Administrator console needs PowerShell to execute its commands.

Figure 5: PowerShell is used

As we are using Hyper-V RC1, we must update our current version with an update for RC1 downloadable from the connect website. Double-click the file called VMM2008_Beta_ServerUpdate.exe and install it.

Using the VMM Administrator Console

So far so good. We have installed our software. Now is the time to launch our management console and see what we can do with it. Go to Microsoft System Center => Virtual Machine Manager 2008 and launch the virtual machine administrator console. You will need to input your FQDN:8100 in the input box and make it your default server (or use localhost:8100 when you installed the admin console on the VMM server itself). Make sure your console is installed on a workstation or server that is joined to the domain as credentials are passed by default!

Figure 6: Connecting to the VMM Server

Adding a host in VMM

The very first step when using VMM is adding a host. This can be a Hyper-V, Virtual Server 2005 R2 or ESX host. Before we start adding the actual host, we will create a host group. By creating host groups, you can customize your views of virtual machine hosts and the virtual machines deployed on them. They can be used to adjust the amount of resources reserved for the host operating system on hosts within the host group. You can compare it more or less with resource pools in VMware’s VirtualCenter.

Figure 7: Resource pools anyone?

Create a new group called HyperV by right-clicking All Hosts and selecting New host group.

Figure 8: Creating a host group

Click on the Hosts button in the left pane and click the Add Hosts link on the right. Notice the Add VMware VirtualCenter Server link. This feature is used to add your VitrtualCenter server to VMM and will be explored in an upcoming article!

Figure 9: Adding a host

A new wizard will start to guide you through the process. You will need to specify a hostname (in our case HYPERV1). The same process is used as in VirtualCenter: VMM will actually push an agent on the target and will request all necessary information (like Virtual Machines, network and storage configuration, etc). Note that Hyper-V does not have to be installed on a Windows x64 2998 host. If the Hyper-V role is not enabled it can be activated by VMM.

Figure 10: The add host wizard

Make sure you add the host to our freshly created HyperV hosts folder. Another thing to note here is the View Script button with the PowerShell icon. You guessed it! Clicking the button reveals all underlying PowerShell code executed. Interesting! Every task performed in VMM can be scripted in PowerShell. Looking at the code generated by the GUI is without doubt a good place to start. We will explore its real power in an upcoming article using PowerShell to manage your VI3.5 and Hyper-V environment.

Figure 11: PowerShell all the way

The host will be added to the VMM and all virtual machines currently running on it will be added to the VMM inventory. Important note: we experienced a problem during host refresh. If you get a refresh error during host connection, make sure there are no USB devices connected! To view all virtual machines running on the host, click on the Virtual Machines link in the left pane.

Figure 12: Your new Hyper-V host is up and running

Conclusion

System Center Virtual Machine Manager 2008 is still in beta now but looks promising. However, it still lacks some (advanced) features like DRS and HA when compared to VMware’s VirtualCenter. In fact, if you want to manage your VI 3.x environment with VMM you will need to have a VirtualCenter up and running. This means 2 management servers...

In Part 2 we will discuss how to create new virtual machines, using the VMM library (templates and guest OS profiles), end-user VM provisioning and physical-to-virtual (P2V).

Understanding VMware ESX Server Security Profiles

2008-08-06T23:54:00.000-07:00

Taking a look at the VMware ESX Server security profile: how security profiles are the firewall of ESX Server, why they are so important, and how to configure them.

Introduction

VMware ESX Server’s built-in software firewall is called the “security profile” for the host server. To be clear, this firewall is the firewall for the entire host – including the service console (if it is not an ESXi server) but not the virtual guests running on the host. Personally, I wish that it was just called the “firewall”, but the term “security profile” has “grown on me”. I hope that after you read this article it will stick in your mind as well. Let’s learn how it works, how to configure it in the GUI & CLI, and why it is important to you as a VMware Admin.

How does the VMware ESX Server Security Profile work?

As the VMware ESX Server security profile is the software firewall of the ESX Server its job is to monitor both inbound and outbound TCP & UDP ports to and from the ESX server. This is done in order to protect the server from network attack.

By default, only specific inbound connections are allowed to a VMware ESX Server. Specifically, (on an ESX 3.5 Server) only SSH and ports related to the VMware Infrastructure & Virtual Center management services are allowed inbound. If you want to access the server with any other applications, inbound, you will have to open that specific port.

Why is the VMware ESX Server Security Profile so important to you as an ESX Server Admin?

The VMware ESX Server Security Profile is important to you, as an ESX Server Admin for a few reasons:

So that you can understand how your ESX Server is protected from attack and so that you can properly secure your server.
If there are ESX services that you want to enable, such as FTP or NTP, you will need to open security profile ports.
If you install any 3rd party applications on the server, you may need to open ports.

How do I configure Security Profiles in the VMware ESX Server VI Client?

To configure security profiles in the VMware Infrastructure Client (VI Client), open the client, log in, and click on an ESX Server, as you see in Figure 1 below.

Figure 1: Accessing the VMware ESX Server Security Profile

Next, you would click on the Configuration tab, then on Security Profile (under Software), as you see in Figure 1.

From here, you can see (on the left) what security profile (firewall) ports are opened on your server (both inbound and outbound). For example, on this server, you can see that SSH and CIM services (used for the VI Client and Virtual Center) are all opened, inbound. Outbound, SSH, Virtual center, VMware License server, iSCSI, NTP, and VCB are all open.

Figure 2: Viewing Security Profile Status and Configuring Security Profile Properties

So how do you change what ports are open, inbound and outbound? The answer is to click on the Properties for the security profile, as you see in Figure 2, above.

Once you click on the security profile properties, you will get a new window that looks like this:

Figure 3: Configuring Security Profile Properties

From the Security Profile properties window, you can enable the preconfigured applications & ports.

Let’s say that we wanted to enable SNMP services inbound and outbound. To do this, just check the checkbox next to that service. In our case, I enabled the SNMP Server port, allowing UDP traffic on port 161 inbound and UDP traffic on port 161. Notice that SNMP is not connected to a particular daemon, as the SSH server is. To apply changes, click OK.

There are times when you need to open a port in the firewall for various applications. For example, if you want to use iSCSI.

If a port is connected to a daemon and you select that port, you can click on the Option button for that port and see the services associated with it, like this:

Figure 4: Daemon / Service Properties

As I did not want to make any changes to the service, I just clicked OK.

Notice that you are limited to the preconfigured applications and whatever their specific inbound or outbound port that is preconfigured for that application. Plus, from the GUI interface, you cannot add any new ports or applications.

How do I configure the ESX Server security profile from the command line (CLI)?

To configure the security profile from the command line, use the esxcfg-firewall command. You would first, of course, have to SSH to the ESX Server and log in first before you can use this command.

The command syntax is simple. To see all the command options, just type the esxcfg-firewall command by itself, and press enter (see Figure 5, below).

Figure 5: esxcfg-firewall command syntax

To view open ports, use the esxcfg-firewall -q command line option.

To open a specific port, you would type a command similar to this:

[root@ESX3 root]# esxcfg-firewall -o 1000,tcp,in,test

However, don’t expect your CLI change to show up in the GUI interface.

You can also configure a port range, like this:

[root@ESX3 root]# esxcfg-firewall -o 1000:1050,tcp,in,test

Understanding and Using Microsoft Windows Server 2008 Hyper-V Snapshots

2008-08-06T23:48:00.000-07:00

How the snapshot feature works in Microsoft Windows Server 2008 Hyper-V, as well as how to create a snapshot and revert to the previous snapshot using the Hyper-V Manager.

What is a Hyper-V Snapshot?

If you use Microsoft Virtual Server 2005 R2 in a test and development or support environment, you probably quickly figured out how to employ differencing and undo virtual hard disks (VHDs) to create hierarchies of virtual machines with incremental configuration variations and rollback capabilities. You can much more easily implement these types of environments using the new Hyper-V snapshot feature, which allows you to capture the configuration and state of a virtual machine at any particular point in time, and provides you with the ability to load any existing snapshot within a matter of seconds.

How does Hyper-V Create a Snapshot?

There are three distinctive elements included in Hyper-V: a Windows hypervisor, child partitions, and a parent partition. The Windows hypervisor runs directly above the hardware and ensures the isolated execution of the parent and child partitions. The role of a child partition is to provide a virtual machine environment to install and execute guest operating systems and applications. Lastly, the parent partition is a special virtual machine that executes Windows Server 2008 and controls the creation and operations of child partitions.

The parent partition creates and manages child partitions through a set of components referred to as the virtualization stack. One of the components in the virtualization stack is the Virtual Machine Management Service (VMMS). The VMMS includes many critical subcomponents, including the Worker Process Manager (WPM) and the Snapshot Manager (SM). The WPM creates a Virtual Machine Worker Process (VMWP) for each virtual machine when it is started. The VMWP manages the creation of snapshots for a virtual machine that is in an online state (started and running). If a virtual machine is offline, and therefore does not have an active VMWP, the Snapshot Manager handles the snapshot creation process.

Figure 1 shows the default virtual machine folder and file set which includes:

A folder that stores one or more virtual hard drives (VHDs) containing the operating system files, application files, and data.
A Snapshots folder that originally does not contain any files.
A Virtual Machines folder that contains an XML-based virtual machine configuration file named using a globally unique identifier (GUID), and a folder named with the same GUID that contains two files. The first file is a saved state file (named using the same GUID as the XML file with a .VSV extension) that is used to store virtual machine state information, such as processor register data. The second file is a binary file (also named with the same GUID as the XML file with a .BIN extension) that is used to store the virtual machine memory contents.

Figure 1: Default virtual machine folder and files before a snapshot

In Figure 1, you can see that the default location for the VHD folder is C:\Users\Public\Documents\Microsoft Hyper-V\Virtual Hard Disks, and that Snapshots and Virtual Machines folders are located in C:\ProgramData\Microsoft\Windows\Hyper-V. These folder locations can easily be modified in the Hyper-V settings using the Hyper-V Manager console.

For a virtual machine without snapshots, all changes made to the virtual machine guest operating system files, application files, and data are applied to the VHDs associated with the virtual machine. Any state information is stored in the .VSV and .BIN files. If you make changes to the virtual machine settings, the changes are reflected in the XML configuration file.

Essentially, the snapshot creation process results in several new files associated with the virtual machine. As shown in Figure 2, the Snapshot Manager creates the following folders and files in the Snapshots folder:

A new folder named using the original GUID. In this folder, a new differencing VHD is created for each parent VHD associated with the virtual machine. The new differencing VHD has the name of the original VHD appended with a new GUID and ends with a .AVHD extension.
A copy of the original virtual machine configuration file named using a new GUID and .XML extension
A new folder named using the same GUID as the new XML file. This folder contains the saved state file (.VSV) and binary file (.BIN) which are created during the virtual machine snapshot. Both files are named with the same GUID as the new folder.
The original virtual machine configuration file is updated to replace the original VHD filenames with the new differencing drives.

Figure 2: Virtual machine folders and files after a snapshot

Once a snapshot is created, all guest operating system, application, and data changes made during the execution of the virtual machine are stored in the associated differencing VHDs. If a virtual machine is offline or powered-down when a snapshot is created, there is no virtual machine state or memory contents to save.

For each subsequent snapshot that is created, a new set of folders and files is generated to capture the virtual machine state and configuration. One important item to note is that the new differencing disks created for each subsequent snapshot are related in a parent and child hierarchy with the original VHDs as the top-level nodes.

Creating a Snapshot

In order to create a snapshot of a virtual machine, you can use the Hyper-V Manager. This is an MMC-based console that is enabled when the Hyper-V role is added to Windows Server 2008. As shown in Figure 3, simply right-click on the virtual machine and select the Snapshot option from the menu.

Figure 3: Creating a virtual machine snapshot using the Hyper-V Manager console

Figure 4 illustrates the changes in the Hyper-V Manager console when the snapshot completes. Basically, the Snapshots section now shows a tree structure that reflects the existing virtual machine snapshot hierarchy. The root node of the tree is the snapshot that was just created and includes the creation timestamp. Under the root node, there is a child named Now which represents the running version of the virtual machine.

Figure 4: Snapshot display in the Hyper-V Manager console

As you make changes to the configuration of a virtual machine, you can create and save additional snapshots. For example, if you want to load and test multiple applications on a particular virtual machine, you can load one application at a time, test it, and take a snapshot of the virtual machine before proceeding to load and test the next application. As shown in Figure 5, snapshots that are generated after the initial one are displayed in a parent and child hierarchy that also reflects the relationship of the differencing disks that are created during each snapshot to capture changes to the virtual machine operating system, application, and data.

Figure 5: Snapshot hierarchy display in the Hyper-V Manager console

Reverting to a Previous Snapshot

If after making a series of changes to a virtual machine you decide that you need to go back to the previous snapshot, Hyper-V provides a Revert option to perform this action as shown in Figure 6. Once the Revert option is applied to a virtual machine, the resulting configuration and state of the virtual machine are returned to the settings saved in the snapshot files. This means that any and all configuration changes made since the snapshot was created including virtual hardware modifications to RAM, number of processors, virtual hard disk adapters, and so on, will be lost.

Figure 6: Using the Snapshot Revert Option in the Hyper-V Manager console

When a Revert is performed, the running virtual machine is stopped and the active differencing disks (.AVHD) are deleted. New differencing disks are created and named using a new GUID. The virtual machine configuration saved during the snapshot is reinstated and the names of the new active differencing disks are updated. The virtual machine is then restarted and the save state files (.VSV and .BIN) are loaded. If the snapshot was created when the virtual machine was powered-off, then there are no save state files to load and the virtual machine remains powered-off.

Slipstreaming Hyper-V RTM

2008-08-06T23:43:00.000-07:00

The process of using the Windows Automated Installation Kit (WAIK) for Windows Server 2008 to slipstream the Hyper-V RTM update and the integration components.

Windows Server 2008 shipped with the Beta 1 version of the Hyper-V role. Microsoft will probably provide updated media at some point in the future, but until then, having an ISO with the final version of Hyper-V and the guest integration components slip streamed into the media can drastically simplify your installation experience of the Hyper-V hosts and virtual machines. In this article, I will walk you through the process of using the Windows Automated Installation Kit (WAIK) for Windows Server 2008, to slipstream the Hyper-V RTM update and the integration components.

Introduction

Windows Server 2008 provides a new servicing model that allows you to integrate update patches and drivers directly into the Install.wim so they can be installed as part of the primary installation routine. Install.wim actually contains six installation images: Standard, Enterprise, and Datacenter using Full Install, and Standard, Enterprise, and Data Center using Server Core Install.

The steps required to create a new Windows Server 2008 ISO that can be used to install either a Hyper-V host or a Windows Server 2008 virtual machine are as follows:

Install the WAIK on your machine.
Extract an RTM Windows Server 2008 DVD to a subdirectory.
Copy the Install.wim from the subdirectory.
Mount the Install.wim with imagex.
Integrate the Hyper-V RTM update with pkgmgr.
Create a new ISO.

Required Software and Tools

In order to perform the slipstream process you will need the following:

The Windows Automated Installation Kit (WAIK) to accomplish the slipstreaming
Windows Server 2008 x64 DVD in physical or ISO format
Hyper-V RTM update file KB950050 x64 version
DVD burner (if you want to create a new physical DVD)

Installing the WAIK

Installing the WAIK is a simple process. You first download the Windows Server 2008 version. You can either burn it to a DVD and install it or use your favorite virtual CD/DVD tool to mount it directly on the host.

Install WAIK by inserting the disk in your machine and the clicking the Windows AIK Setup option on the welcome screen highlighted in Figure 1.

Figure 1: WAIK Installation Screen

The Installation process is a quick three step process that involves accepting the EULA, accepting the default installation folder, and completing the installation. Once installed, you can exit the dialog by selecting the Exit option on the WAIK welcome screen.

Extract the Windows Server 2008 DVD

Now you need to get a read-write copy of the Windows Server 2008 x64 DVD so that you can update the install.wim with a version you build by slipstreaming the Hyper-V RTM update and integration components.

Create a C:\NewWin2008ISO folder on your machine
Copy all the contents of the Windows Server 2008 DVD to C:\NewWin2008ISO

Extract the Hyper-V RTM Update

In order to integrate the update into the install.wim, you need the cab file from the Windows Update installation package.

Download the Hyper-V RTM update for x64 and place it in C:\Hyper-V-Update
Make a directory called C:\EXTRACT
Expand the Hyper-V RTM update using the following command line

expand -F:* C:\Hyper-V-Update\Windows6.0-KB950050-x64.msu C:\extract

Mount the Install.wim to Slipstream Updates

Now you will modify the install.wim file with updates and drivers. To be safe, you should make a separate copy that you can mount with imagex and modify without modifying the original in the C:\NewWin2008ISO folder.

Create a C:\WIM folder on your machine.
Copy the C:\NewWin2008ISO\SOURCES\INSTALL.WIM to C:\WIM.
Open an elevated Windows PE Tools command prompt by going to the Microsoft Windows AIK program menu, right clicking the Windows PE Tools Command Prompt option, and selecting Run As Administrator.The install.wim has the following images included with the indicated indexes.

The install.wim has the following images included with the indicated indexes.

Index Number	Name
1	Windows Longhorn SERVERSTANDARD
2	Windows Longhorn SERVERENTERPRISE
3	Windows Longhorn SERVERDATACENTER
4	Windows Longhorn SERVERSTANDARDCORE
5	Windows Longhorn SERVERENTERPRISECORE
6	Windows Longhorn SERVERDATACENTERCORE

You actually need to update each product individually, but I will show you how to do one and you can repeat the process for the other five images if needed.

Run the following command to mount the Windows Server 2008 Server Core x64 Enterprise Edition:

Imagex /mountrw

Imagex /mountrw C:\WIM\INSTALL.WIM 5 C:\MNT

Integrate the RTM update

Now you can integrate the Hyper-V update cab that you extracted earlier.

Integrate the RTM update cab file into the install.wim using pkgmgr.

start /w pkgmgr /ip /m:C:\extract\Windows6.0-KB950050-x64.cab /o:c:\mnt;c:\mnt\windows /s:%temp%

Where:

/ip – install a single package
/m – path to the extracted package
/o – offline installation locations: system_drive_path; offline_Windows_directory_path
/s – Temporary working directory to extract files if required

Pkgmgr command line reference information.
Check for success (if the error level is zero, then continue)

Echo %errorlevel%

You can also look in C:\MNT\WINDOWS\SERVICING\PACKAGES and you should see the package files for KB950050 integrated at the bottom of the list.

If everything ran successfully, then unmount the install.wim and commit the changes.

imagex /unmount /commit c:\mnt

Lather, Rinse, and Repeat

Unfortunately, you have only updated one out of the six images in the Install.wim file. If you want to update all of them, you need to repeat the following processes for each image index:

Mount the install.wim using the new image index value.
Slipstream the Hyper-V update using the pkgmgr tool.
Unmount and commit the changes.

Build new ISO

Once you have updated all of the images within the install.wim file, it is time to build a new ISO file. The WAIK comes with a nice tool called OSCDIMG to do this and it even allows you to specify the boot file so that the ISO is bootable.

Copy the updated C:\WIM\INSTALL.WIM to C:\NewWin2K8ISO\Sources\ , overwriting the existing copy.
Use the OSCDIMG tool from the WAIK to create a new ISO. Using the elevated Windows PE Tools command prompt.

Oscdimg –n –m –bc:\NewWindows2008ISO\BOOT\ETFSboot.com C:\NewWindows2008ISO C:\Win2008Hyper-V-RTM.ISO
Burn the ISO to DVD or place the ISO somewhere it is easy to get to when creating virtual machines. When you create a new Hyper-V host the RTM update will automatically be installed. When you create a Windows Server 2008 virtual machine using the ISO, the integration components will automatically be installed.

Managing Unified Messaging Auto Attendant (Part 1)

2008-08-06T03:38:00.001-07:00

How to record personalized voice prompts and create a UM Auto Attendant in Exchange Server 2007.

Introduction

Note:
We will use square brackets to represent voice messages in this article []. When you see something like: [Hello World!] it is voice content.

Recording the Voice Prompts to be used with UM Auto Attendant

We are going to use the most common voice recorder: the sound recorder that comes with Windows XP and Windows 2003. In order to record the customized voice prompts follow these steps:

Click on Start, Programs, Accessories, Entertainment.
Click on Sound Recorder.
Click on the Rec button to record and start speaking at the first Custom Voice Prompt.Click on the Stop button as soon as you finish the first prompt.
Click on File menu, and then click on Properties.
Click on Convert now…
Configure the format and attributes for PCM, 8 kHz, 16 Bit, Mono (Figure 01) and click on OK.

Figure 01

Now you can save your recorded voice prompt with an appropriate name to be used in the Auto Attendant.9.Repeat these steps for each prompt that you want to record.

Greeting	Default example	Customized Prompts	File Name
Business hours greeting	"Welcome to the Exchange auto attendant."	[Welcome to CompanyName.]	MainAA_Greeting_business.wav
Non-business hours greeting	-	[Thank you for calling CompanyName Our regular business hours are from 09:00 AM to 6:00 PM]	MainAA_Greeting_non-business.wav
Informational announcement	-	[To continue using this Auto Attendant you must be aware of our internal security rule SEC-171]	MainAA_Greeting_informational.wav
Business hours main menu prompt	-	[You can use the following options: For the Sales Department, press 1 or just say Sales. For the Support Department, press 2 or just say Support. For information about business hours and locations, press 3 or just say business hours and locations. If you know your party’s name, just say it.]	MainAA_Greeting_mainbusiness.wav
Non-business hours main menu prompt	-	[You can use the following options: For 24x7 support, press 1 or just say support. For information about business hours and locations, press 3 or just say business hours and locations.]	MainAA_Greeting_mainNonbusiness.wav

Table 1

This table above is only to get the general idea, be aware that you can create and probably you will need more personalized voice prompts to customize your Auto Attendant deployment.

Creating a Unified Messaging Auto Attendant

After recording the voice prompts that will be used by our first UM Auto Attendant, we can create our first UM Auto Attendant:

Open the Exchange Management Console.
Expand Organization Configuration.
Click on Unified Messaging.
Click on the UM Auto Attendants tab.
In the Toolbox Actions click on New UM Auto Attendant…
B>New UM Auto Attendant. This wizard defines (Figure 02) the UM Auto Attendant name and extension numbers which callers will use to reach the UM Auto Attendant. We also have two options at the bottom of the wizard: the first one (Create auto attendant as enabled) is self explanatory and the second option (Create auto attendant as speech-enabled) will allow the UM Auto Attendant to receive voice commands from the callers to improve the user experience. By default a UM Auto Attendant is not created as speech-enabled, this means we can only use the touchtone to interact with the UM Auto Attendant.
Note: We have a limit of 16 extension numbers per UM Auto Attendant.

Figure 02

Completion. Final screen of the UM Auto Attendant wizard, just click on Finish. (Figure 03)

Figure 03

We can also create UM Auto Attendant using Exchange Management Shell. The cmdlet to be used is New-UMAutoAttendant, and it can be used in the following way:

New-UMAutoAttendant –Name -UMDialPlan -PilotIdentifierList

Conclusion

In this first article we saw a high overview of the UM Auto Attendant feature, how to record our personalized voice prompts and how to create an Auto Attendant.

In the next article we will configure UM Auto Attendant to increase the caller experience using Exchange Server 2007 Unified Messaging.

Testing Exchange 2007 With PowerShell (Part 1)

2008-08-06T03:31:00.001-07:00

A look at some of the cmdlets that are used to test Exchange 2007, what they do and how to use them.

Introduction

After you’ve built and configured your new Exchange 2007 server, one of the first things that you should always do is thoroughly test the system before you put users onto it, even your initial pilot users. Any issues encountered can then be resolved before they affect the users. Microsoft has provided a whole selection of Exchange Management Shell cmdlets that can be used to test the various services and functionality of your Exchange 2007 server before you place it into production. Of course, you can also use these same cmdlets during the lifetime of the server to re-test the functionality should you have any doubts as to whether the server is configured correctly or perhaps even optimally. These cmdlets all start with Test-.

Recently on a project I used the various Test- cmdlets to test the configuration of an Exchange 2007 server environment that had just been built and configured. Throughout this article I will be taking a look at some of the cmdlets that I used. I won’t be covering every cmdlet that can be used to test server functionality since the list is fairly long. Additionally, each cmdlet has a number of different parameters available to it and therefore equally it’s not really feasible to cover them all within this article. What I hope to do, though, is to give you a taster of the sort of tests that can be accomplished via these cmdlets thereby ensuring that you remember to run them the next time you have either recently configured an Exchange 2007 server or you have run into an operational issue that you would like checked out.

Table 1 shows a list of available cmdlets that can be used for testing purposes with those in the shaded rows being covered in this two-part article. The cmdlets won’t be covered in any particular order. In this article, I’ll cover the Test-ServiceHealth and Test-OutlookWebServices cmdlet whilst the remainder will be covered in part two.

Cmdlet Name	Purpose
Test-ActiveSyncConnectivity	Tests the configuration of ActiveSync against a mailbox
Test-EdgeSynchronization	Tests the synchronization status of subscribed Edge Transport servers
Test-ExchangeSearch	Tests the content indexing service for correct functionality
Test-ImapConnectivity	Tests the IMAP4 service for correct functionality
Test-IPAllowListProvider	Tests the configuration of the IP Allow List provider
Test-IPBlockListProvider	Tests the configuration of the IP Block List provider
Test-Mailflow	Tests the sending and receiving of email
Test-MapiConnectivity	Tests that a mailbox can be logged onto properly
Test-OutlookWebServices	Tests the Autodiscover service settings
Test-OwaConnectivity	Tests that Outlook Web Access is functioning correctly
Test-PopConnectivity	Tests the POP3 service for correct functionality
Test-ReplicationHealth	Tests the health of storage group replication
Test-SenderId	Tests the Sender ID process
Test-ServiceHealth	Tests that all required services have started successfully
Test-SystemHealth	Tests the overall configuration of your Exchange organization
Test-UMConnectivity	Tests the operation of a Unified Messaging server
Test-WebServicesConnectivity	Tests the functionality of Outlook Anywhere

Table 1: List of Test Cmdlets

Test-ServiceHealth

Let’s start off with a nice easy one, the Test-ServiceHealth cmdlet. With the new roles present in Exchange 2007, one thing that has changed over legacy versions of Exchange is that each Exchange server will now have different services configured on it, depending on the roles that it has to perform. For example, the Microsoft Exchange Transport service will only be seen on transport servers such as those Exchange 2007 servers running the Hub Transport or Edge Transport role. As a quick way of testing whether the required services are present and, more importantly started, you can use the Test-ServiceHealth cmdlet.

You can run the Test-ServiceHealth cmdlet on the local server to test locally installed services, or you can use the –Server parameter to target a remote server. In Figure 1, you can see the results of running this cmdlet on an Exchange 2007 server that has the Mailbox, Hub Transport and Client Access Server roles installed. Notice how the results are separated such that the results for each role are shown. As you can see, the key information is presented in the RequiredServicesRunning column, which obviously indicates a successful test or not. If any required service is not running, the RequiredServicesRunning column will show False with the corresponding service name listed in the ServicesNotRunning column.

Figure 1: Default Results of Test-ServiceHealth

Test-OutlookWebServices

Arguably one of the more confusing new areas of Exchange 2007 is the configuration of the Autodiscover service, particularly the area surrounding certificate names. If the wrong Subject Alternate Names are listed in the certificates or certain configuration areas not completed via other Exchange Management Shell cmdlets, the Autodiscover process will fail. Ultimately for Outlook 2007 users this means that services such as the Offline Address Book will not be available. Fortunately, the Autodiscover configuration can be tested using the Test-OutlookWebServices cmdlet. Since the Autodiscover service runs on the Client Access Server role, it follows that this cmdlet is run against a Client Access Server.

The main parameter to supply with this cmdlet is the –Identity parameter which is used to test the Outlook provider and takes the form of an email address within the forest. Take the example shown in Figure 2 where the results of the Test-OutlookWebServices cmdlet have been piped into the format-list cmdlet. The cmdlet used was:

Test-OutlookWebServices –Identity neil@neilhobson.com | fl

Figure 2: Test-OutlookWebServices Output

What you will notice from the above results is that the AS (Availability Service), OAB (Offline Address Book) and UM (Unified Messaging) services have been successfully contacted using the EXCH Outlook provider using the local server’s Fully Qualified Domain Name (FQDN) but that the same services are not configured for the user via the EXPR Outlook provider. This is revealed by the wording shown in Figure 3.

Id : 1015
Type : Information
Message : [EXPR]-The OAB is not configured for this user.

Figure 3: Missing EXPR Outlook Provider Configuration

These results are a sign that some configuration elements have not been completed. To confirm this is the case, the Get-WebServicesVirtualDirectory, Get-OabVirtualDirectory and Get-UMVirtualDirectory cmdlets can be run and the output examined, where it should be seen that the –ExternalUrl parameter is blank. For example, look at Figure 4 where the Get-OabVirtualDirectory cmdlet has been run with the results piped to the format-list cmdlet and filtered to only show the ExternalUrl parameter.

Figure 4: Get-OabVirtualDirectory Output

The –ExternalUrl parameter controls the URL that Outlook uses to retrieve the OAB when running on an external network or when non-domain joined. Conversely, on the internal network, Outlook will retrieve the OAB via the –InternalUrl parameter which, by default, will be set to the FQDN of the Client Access Server. However, you will need to manually configure the –ExternalUrl parameter which in this example would be set to something like https://autodiscover.neilhobson.com/oab. I’m not going to discuss at length the Autodiscover service here since that’s not the focus of this article. The key thing that you need to take away from this article is that when you see a service described as “not configured for this user” when using the Test-OutlookWebServices parameter, it’s likely that one or more –ExternalUrl parameters are missing. Don’t forget that there are configurations for the Availability Service, the OAB and Unified Messaging. Therefore, there are three cmdlets to run to configure the external URL accordingly. For example, assuming a Client Access Server name of CAS1 and an external domain name of neilhobson.com, the three configuration cmdlets would be:

Set-WebServicesVirtualDirectory –Identity “CAS1\EWS (Default Web Site)” –ExternalUrl https://autodiscover.neilhobson.com/EWS/Exchange.asmx

SetOabVirtualDirectory –Identity “CAS1\OAB (Default Web Site)” –ExternalUrl https://autodiscover.neilhobson.com/oab

Set-UMVirtualDirectory –Identity “CAS1\UnifiedMessaging (Default Web Site)” –ExternalUrl https://autodiscover.neilhobson.com/UnifiedMessaging/Service.asmx

Once these have been set you can re-run the Test-OutlookWebServices cmdlet where you should see a successful test using the EXPR Outlook provider. A sample of the wording similar to what you’d expect to see is shown in Figure 5.

Id : 1015
Type : Success
Message : [EXPR]-Successfully contacted the OAB service at https://autodiscover
.neilhobson.com/ews/exchange.asmx. The elapsed time was 0 milliseconds.

Figure 5: Successful Test of EXPR Outlook Provider

How to install an SSH Server in Windows Server 2008

2008-08-06T02:52:00.000-07:00

How to install an SSH Server in Windows Server 2008.

Introduction

There are a number of command line options available to configure Window Server 2008 over the network. For example, Windows Powershell, ServerManager.exe, or a telnet server. However, the tried and true method that has worked so well with just about every type of infrastructure device in use today (including Windows Server 2008, Cisco Routers, Linux servers, and more) is SSH. In this article, learn how to install a SSH Server in Windows Server 2008.

What is SSH?

SSH is the secure shell, a standard defined in RFC 4251. It is a network protocol that opens up a secure channel between two devices using TCP port 22. This channel can also be used for SFTP and SCP (secure FTP and secure copy, respectively). To make this work, you need a secure server on the system you are connecting to and a secure client on the client you are connecting from.

Keep in mind that SSH is completely interoperable between different platforms. For example, you could connect to a SSH server on a Cisco router from a Windows client, you could connect to a Linux server from a Cisco router, and you could connect to a Windows 2008 Server from a Linux client.

The only possible compatibility issue is that there are two versions of SSH, SSH version 1 and SSH version 2. You should make sure that the server and client support the same versions so that you know which version you are using when you connect. Usually, this version can be negotiated.

While none of the Windows operating systems come with a SSH Server or Client, they are very easy to install.

By having a SSH Server on your Windows 2008 Server, you can:

Remotely access the command line of your Windows 2008 Server
Control the Server over the network, even if you cannot access the GUI interface
Remotely manage your Windows 2008 Server from any device that has a SSH Client
Do all this over an encrypted connection that could even securely traverse the Internet

How do I install FreeSSHd - SSH Server in Windows Server 2008?

Because the installation for Free SSHd is so simple as compared to others (especially as compared to OpenSSH in Windows), I have chosen to demonstrate how to install and use Free SSHd. Remember that FreeSSHd is totally free (as the name says) both for personal / non-commercial use but also for commercial use.

To start this process, I downloaded FreeSSHd.exe on my Windows Server 2008 system and ran the downloaded program. The graphical installation began.

I took all the defaults for the installation options and clicked Install to being the install.

When done, I opted not to run SSHd as a service but that may be what you want to do on your production server.

Figure 1: Do you want to run FreeSSHd as a service?

By running FreeSSHd as service, it would be available no matter if you were logged into the console or not. I also chose to create private keys for the SSH server.

Next, I ran the FreeSSHd shortcut on the desktop in order to configure and start the SSH server

Figure 2: Running the FreeSSH Application

I could see that the SSHd server was already running.

The FreeSSHd application can offer the following:

Both SSH Server and Telnet Server capabilities
Options to run SSHd on only certain interfaces
Multiple methods of authentication, including integrated NTLM authentication to Windows AD
Multiple methods of encryption including AES 128, AES 256, 3DES, Blowfish, and more
Options to bring up a secure tunnel upon connection
Optional Secure FTP (sFTP) - for secure FTP, see the FreeFTPd website
The ability to administer users and restrict access to secure shell, secure tunnel, or secure FTP
Ability to allow access to only certain hosts or subnets
Ability to log all connections and commands performed through FreeSSHd
View currently connected users
Update FreeSSHd automatically

For me to be able to login, I had to do two things:

Add a new user account and allow SSH command line access
Open an exception in my Windows Server 2008 Firewall

To add a new user, I went to the Users tab and clicked Add.

I opted to set up a login for my local Windows administrator account. I set the authorization to NTLM. That way, there was no local password in the FreeSSHd database and if the administrator password changes in the local Windows account database, you don’t have to change the password in the FreeSSHd account database.

I authorized this new administrator SSH user to log in with SSH only.

Figure 3: Adding a SSHd user account with NTLM authorization

Here are the results:

Figure 4: A new SSHd user account added

The second thing I had to do to allow me to login was to open an exception in the Windows Firewall. While I could disable the Windows Firewall completely instead of opening the ports, of course the most secure option is to leave the firewall up and allow for an exception for SSH – TCP port 22.

To do that, I went to Start -> Administrative Tools -> Windows Firewall with Advanced Security.

Figure 5: Opening Windows Firewall with Advanced Security

Next, I clicked on Inbound Rules, then on New Rule.

Figure 6: Adding a new Inbound Rule

Next, I chose to add a Port rule.

Figure 7: Choosing to add a Rule for a Port

I specified TCP port 22 only.

Figure 8: Specifying TCP port 22 only

Take the defaults to Allow the Connection, apply this to All domains, and give the rule a Name of your choice.

Test the Connection

To test the connection, I used SecureCRT from my Windows XP machine to the Windows Server 2008 server, via SSH.

To do this, I connected to the server via the IP address (or domain name). I chose to Accept the server’s certificate and save it.

Figure 9: Connecting via SSH and logging in with your Windows username & password

I logged into the server using the administrator login and password.

And, success! I was able to access the server via SSH!

Figure 10: A successful connection to the Windows 2008 Server via SSH

In Summary

SSH is an excellent tool for Windows Server 2008 administrators to consider for remote server management. In this article, you learned how SSH can help you, the options available for SSH Server and SSH Client installations, and how to install one of those options, FreeSSHd.

Networking Basics: Part 20 - File Level Permissions

2008-08-04T04:32:00.000-07:00

Networking Basics: Part 1 - Networking Hardware

2008-08-04T04:22:00.000-07:00

In this article series, I will start with the absolute basics, and work toward building a functional network. In this article I will begin by discussing some of the various networking components and what they do.

In the past, all of the articles that I have written for this Web site have been intended for use by administrators with at least some level of experience. Recently though, there have been requests for articles targeted toward those who are just getting started with networking and that have absolutely no experience at all. This article will be the first in a series targeted toward novices. In this article series, I will start with the absolute basics, and work toward building a functional network. In this article I will begin by discussing some of the various networking components and what they do.

Network Adapters

The first piece of hardware that I want to discuss is a network adapter. There are many different names for network adapters, including network cards, Network Interface Cards, NICs. These are all generic terms for the same piece of hardware. A network card’s job is to physically attach a computer to a network, so that the computer can participate in network communications.

The first thing that you need to know about network cards is that the network card has to match the network medium. The network medium refers to the type of cabling that is being used on the network. Wireless networks are a science all their own, and I will talk about them in a separate article.

At one time making sure that a network card matched the network medium was a really big deal, because there were a large number of competing standards in existence. For example, before you built a network and started buying network cards and cabling, you had to decide if you were going to use Ethernet, coaxal Ethernet, Token Ring, Arcnet, or one of the other networking standards of the time. Each networking technology had its strengths and weaknesses, and it was important to figure out which one was the most appropriate for your organization.

Today, most of the networking technologies that I mentioned above are quickly becoming extinct. Pretty much the only type of wired network used by small and medium sized businesses is Ethernet. You can see an example of an Ethernet network card, shown in Figure A.

Figure A: This is what an Ethernet card looks like

Modern Ethernet networks use twisted pair cabling containing eight wires. These wires are arranged in a special order, and an RJ-45 connecter is crimped onto the end of the cable. An RJ-45 cable looks like the connector on the end of a phone cord, but it’s bigger. Phone cords use RJ-11 connectors as opposed to the RJ-45 connectors used by Ethernet cable. You can see an example of an Ethernet cable with an RJ-45 connector, shown in Figure B.

Figure B: This is an Ethernet cable with an RJ-45 connector installed

Hubs and Switches

As you can see, computers use network cards to send and receive data. The data is transmitted over Ethernet cables. However, you normally can’t just run an Ethernet cable between two PCs and call it a network.

In this day and age of high speed Internet access being almost universally available, you tend to hear the term broadband thrown around a lot. Broadband is a type of network in which data is sent and received across the same wire. In contrast, Ethernet uses Baseband communications. Baseband uses separate wires for sending and receiving data. What this means is that if one PC is sending data across a particular wire within the Ethernet cable, then the PC that is receiving the data needs to have the wire redirected to its receiving port.

You can actually network two PCs together in this way. You can create what is known as a cross over cable. A cross over cable is simply a network cable that has the sending and receiving wires reversed at one end, so that two PCs can be linked directly together.

The problem with using a cross over cable to build a network is that the network will be limited to using no more and no less than two PCs. Rather than using a cross over cable, most networks use normal Ethernet cables that do not have the sending and receiving wires reversed at one end.

Of course the sending and receiving wires have to be reversed at some point in order for communications to succeed. This is the job of a hub or a switch. Hubs are starting to become extinct, but I want to talk about them any way because it will make it easier to explain switches later on.

There are different types of hubs, but generally speaking a hub is nothing more than a box with a bunch of RJ-45 ports. Each computer on a network would be connected to a hub via an Ethernet cable. You can see a picture of a hub, shown in Figure C.

Figure C: A hub is a device that acts as a central connection point for computers on a network

A hub has two different jobs. Its first job is to provide a central point of connection for all of the computers on the network. Every computer plugs into the hub (multiple hubs can be daisy chained together if necessary in order to accommodate more computers).

The hub’s other job is to arrange the ports in such a way so that if a PC transmits data, the data is sent over the other computer’s receive wires.

Right now you might be wondering how data gets to the correct destination if more than two PCs are connected to a hub. The secret lies in the network card. Each Ethernet card is programmed at the factory with a unique Media Access Control (MAC) address. When a computer on an Ethernet network transmits data across an Ethernet network containing PCs connected to a hub, the data is actually sent to every computer on the network. As each computer receives the data, it compares the destination address to its own MAC address. If the addresses match then the computer knows that it is the intended recipient, otherwise it ignores the data.

As you can see, when computers are connected via a hub, every packet gets sent to every computer on the network. The problem is that any computer can send a transmission at any given time. Have you ever been on a conference call and accidentally started to talk at the same time as someone else? This is the same thing that happens on this type of network.

When a PC needs to transmit data, it checks to make sure that no other computers are sending data at the moment. If the line is clear, it transmits the necessary data. If another computer tries to communicate at the same time though, then the packets of data that are traveling across the wire collide and are destroyed (this is why this type of network is sometimes referred to as a collision domain). Both PCs then have to wait for a random amount of time and attempt to retransmit the packet that was destroyed.

As the number of PCs on a collision domain increases, so does the number of collisions. As the number of collisions increase, network efficiency is decreased. This is why switches have almost completely replaced hubs.

A switch, such as the one shown in Figure D, performs all of the same basic tasks as a hub. The difference is that when a PC on the network needs to communicate with another PC, the switch uses a set of internal logic circuits to establish a dedicated, logical path between the two PCs. What this means is that the two PCs are free to communicate with each other, without having to worry about collisions.

Figure D: A switch looks a lot like a hub, but performs very differently

Switches greatly improve a network’s efficiency. Yes, they eliminate collisions, but there is more to it than that. Because of the way that switches work, they can establish parallel communications paths. For example, just because computer A is communicating with computer B, there is no reason why computer C can’t simultaneously communicate with computer D. In a collision domain, these types of parallel communications would be impossible because they would result in collisions.

Networking Basics: Part 2 - Routers

2008-08-04T04:19:00.000-07:00

This article continues the discussion of networking hardware by talking about one of the most important networking components; routers.

In the first part of this article series, I talked about some basic networking hardware such as hubs and switches. In this article, I want to continue the discussion of networking hardware by talking about one of the most important networking components; routers.

Even if you are new to networking, you have probably heard of routers. Broadband Internet connections, such as those utilizing a cable modem or a DSL modem, almost always require a router. A router's job isn't to provide Internet connectivity though. A router's job is to move packets of data from one network to another. There are actually many different types of routers ranging from simple, inexpensive routers used for home Internet connectivity to the insanely expensive routers used by giant corporations. Regardless of a router’s cost or complexity, routers all work on the same basic principles.

That being the case, I'm going to focus my discussion around simple, low budget routers that are typically used to connect a PC to a broadband Internet connection. My reason for doing so is that this article series is intended for beginners. In my opinion, it will be a lot easier to teach you the basics if I am referencing something that is at least somewhat familiar to most people, and that is not as complicated as many of the routers used within huge corporations. Besides, the routers used in corporations work on the same basic principles as the routers that I will be discussing in this article. If you are wanting a greater level of knowledge though, don’t worry. I will talk about the science of routing in a whole lot more detail later in this article series.

As I explained earlier, a router's job is to move packets of data from one network to another. This definition might seem strange in the context of a PC that's connected to a broadband Internet connection. If you stop and think about it, the Internet is a network (actually it's a collection of networks, but that's beside the point).

So if a router's job is to move traffic between two networks, and the Internet is one of those networks, where is the other one? In this particular case, the PC that is connected to the router is actually configured as a very simple network.

To get a better idea of what I am talking about, take a look at the pictures shown in Figures A and B. Figure A shows the front of a 3COM broadband router, while Figure B shows the back view of the same router.

Figure A: This is the front view of a 3COM broadband router

Figure B: A broadband Internet router contains a set of RJ-45 ports just like a hub or switch

As you can see in the figures, there is nothing especially remarkable about the front view of the router. I wanted to include this view anyway though, so that those of you who are unfamiliar with routers can see what a router looks like. Figure B is much more interesting.

If you look at Figure B, you’ll see that there are three sets of ports on the back of the router. The port on the far left is where the power supply connects to the router. The middle port is an RJ-45 port used to connect to the remote network. In this particular case, this router is intended to provide Internet connectivity. As such, this middle port would typically be used to connect the router to a cable modem or to a DSL modem. The modem in turn would provide the actual connectivity to the Internet.

If you look at the set of ports on the far right, you’ll see that there are four RJ-45 ports. If you think back to the first part of this article series, you’ll recall that hubs and switches also contained large groups of RJ-45 ports. In the case of a hub or switch, the RJ-45 ports are used to provide connectivity to the computers on the network.

These ports work the exact same way on this router. This particular router has a four port switch built in. Remember earlier when I said that a router’s job was to move packets between one network and another? I explained that in the case of a broadband router, the Internet represents one network, and the PC represents the second network. The reason why a single computer can represent an entire network is because the router does not treat the PC as a standalone device. Routers treat the PC as a node on a network. As you can see from the photo in Figure B, this particular router could actually accommodate a network of four PCs. It’s just that most home users who use this type of configuration only plug one PC into the router. Therefore a more precise explanation would be that this type of network routes packets of data between a small network (even if that network only consists of a single computer) to the Internet (which it treats as a second network).

The Routing Process

Now that I've talked a little bit about what a router is and what it does, I want to talk about the routing process. In order to understand how routing works, you have to understand a little bit about how the TCP/IP protocol works.

Every device connected to a TCP/IP network has a unique IP address bound to its network interface. The IP address consists of a series of four numbers separated by periods. For example, a typical IP address looks something like this: 192.168.0.1

The best analogy I can think of to describe an IP address is to compare it to a street address. A street address consists of a number and a street name. The number identifies the specific building on the street. An IP address works kind of the same way. The address is broken into the network number and a device number. If you were to compare an IP address to a Street address, then think of the network number as being like a street name, and at the device number as being like a house number. The network number identifies which network the device is on, and the device number gives the device an identity on that network.

So how do you know where the network number ends and the device number begins? This is the job of the subnet mask. A subnet mask tells the computer where the network number portion of an IP address stops, and where the device number starts. Subnetting can be complicated, and I will cover in detail in a separate article. For now, let's keep it simple and look at a very basic subnet mask.

A subnet mask looks a lot like an IP address in that it follows the format of having four numbers separated by periods. A typical subnet mask looks like this: 255.255.255.0

In this particular example, the first three numbers (called octets) are each 255, and the last number 0. The number 255 indicates that all of the bits in the corresponding position in the IP address are a part of the network number. The number zero indicates that none of the bits in the corresponding position in the IP address are a part of the network number, and therefore they all belong to the device number.

I know this probably sounds a little bit confusing, so consider this example. Imagine that you had a PC with an IP address of 192.168.1.1 and a subnet mask of 255.255.255.0. In this particular case, the first three octets of the subnet mask are all 255. This means that the first three octets of the IP address all belong to the network number. Therefore, the network number portion of this IP address is 192.168.1.x.

The reason why this is important to know is because a router’s job is to move packets of data from one network to another. All of the devices on a network (or on a network segment to be more precise) share a common network number. For example, if 192.168.1.x was the network number associated with computers attached to the router shown in Figure B, then the IP addresses for four individual computers might be:

192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4

As you can see, each computer on the local network shares the same network number, but has a different device number. As you may know, whenever a computer needs to communicate with another computer on a network, it does so by referring to the other computer’s IP address. For example, in this particular case the computer with the address of 192.168.1.1 could easily send a packet of data to the computer with the address of 192.168.1.3, because both computers are a part of the same physical network.

Things work a bit differently if a computer needs to access a computer on another network. Since I am focusing this particular discussion on small broadband routers that are designed to provide Internet connectivity, let’s pretend that one of the users on the local network wanted to visit the www.brienposey.com Web site. A Web site is hosted by a server. Like any other computer, a Web server has a unique IP address. The IP address for this particular Web site is 24.235.10.4.

You can easily look at this IP address and tell that it does not belong to the 192.168.1.x network. That being the case, the computer that’s trying to reach the Web site can’t just send the packet out along the local network, because the Web server isn’t a part of the local network. Instead, the computer that needs to send the packet looks at its default gateway address.

The default gateway is a part of a computer’s TCP/IP configuration. It is basically a way of telling a computer that if it does not know where to send a packet, then send it to the specified default gateway address. The default gateway’s address would be the router’s IP address. In this case, the router’s IP address would probably be 192.168.1.0.

Notice that the router’s IP address shares the same network number as the other computers on the local network. It has to so that it can be accessible to those computers. Actually, a router has at least two IP addresses. One of those addresses uses the same network number as your local network. The router’s other IP address is assigned by your ISP. This IP address uses the same network number as the ISPs network. The router’s job is therefore to move packets from your local network onto the ISPs network. Your ISP has routers of its own that work in exactly the same way, but that route packets to other parts of the Internet.

Networking Basics: Part 3 - DNS Servers

2008-08-04T04:17:00.000-07:00

This article continues the Networking for Beginners series by talking about how DNS servers work.

In the last part of this article series, I talked about how all of the computers on a network segment share a common IP address range. I also explained that when a computer needs to access information from a computer on another network or network segment, it’s a router’s job to move the necessary packets of data from the local network to another network (such as the Internet).

If you read that article, you probably noticed that in one of my examples, I made a reference to the IP address that’s associated with my Web site. To be able to access a Web site, your Web browser has to know the Web site’s IP address. Only then can it give that address to the router, which in turn routes the outbound request packets to the appropriate destination. Even though every Web site has an IP address, you probably visit Web sites every day without ever having to know an IP address. In this article, I will show you why this is possible.

I have already explained that IP addresses are similar to street addresses. The network portion of the address defines which network segment the computer exists on, and the computer portion of the address designates a specific computer on that network. Knowing an IP address is a requirement for TCP/IP based communications between two computers.

When you open a Web browser and enter the name of a Web site (which is known as the site’s domain name, URL, or Universal Resource Locator), the Web browser goes straight to the Web site without you ever having to enter an IP address. With that in mind, consider my comparison of IP addresses to postal addresses. You can’t just write someone’s name on an envelope, drop the envelope in the mail, and expect it to be delivered. The post office can’t deliver the letter unless it has an address. The same basic concept applies to visiting Web sites. Your computer cannot communicate with a Web site unless it knows the site’s IP address.

So if your computer needs to know a Web site’s IP address before it can access the site, and you aren’t entering the IP address, where does the IP address come from? Translating domain names into IP addresses is the job of a DNS server.

In the two articles leading up to this one, I talked about several aspects of a computer’s TCP/IP configuration, such as the IP address, subnet mask, and default gateway. If you look at Figure A, you will notice that there is one more configuration option that has been filled in; the Preferred DNS server.

Figure A: The Preferred DNS Server is defined as a part of a computer’s TCP/IP configuration

As you can see in the figure, the preferred DNS server is defined as a part of a computer’s TCP/IP configuration. What this means is that the computer will always know the IP address of a DNS server. This is important because a computer cannot communicate with another computer using the TCP/IP protocol unless an IP address is known.

With that in mind, let’s take a look at what happens when you attempt to visit a Web site. The process begins when you open a Web browser and enter a URL. When you do, the Web browser knows that it can not locate the Web site based on the URL alone. It therefore retrieves the DNS server’s IP address from the computer’s TCP/IP configuration and passes the URL on to the DNS server. The DNS server then looks up the URL on a table which also lists the site’s IP address. The DNS server then returns the IP address to the Web browser, and the browser is then able to communicate with the requested Web site.

Actually, that explanation is a little bit over simplified. DNS name resolution can only work in the way that I just described if the DNS server contains a record that corresponds to the site that’s being requested. If you were to visit a random Web site, there is a really good chance that your DNS server does not contain a record for the site. The reason for this is because the Internet is so big. There are millions of Web sites, and new sites are created every day. There is no way that a single DNS server could possibly keep up with all of those sites and service requests from everyone who is connected to the Internet.

Let’s pretend for a moment that it was possible for a single DNS server to store records for every Web site in existence. Even if the server’s capacity were not an issue, the server would be overwhelmed by the sheer volume of name resolution requests that it would receive from people using the Internet. A centralized DNS server would also be a very popular target for attacks.

Instead, DNS servers are distributed so that a single DNS server does not have to provide name resolutions for the entire Internet. There is an organization named the Internet Corporation for Assigned Names and Numbers, or ICANN for short, that is responsible for all of the registered domain names on the Internet. Because managing all of those domain names is such a huge job, ICANN delegates portions of the domain naming responsibility to various other firms. For example, Network Solutions is responsible for all of the .com domain names. Even so, Network Solutions does not maintain a list of the IP addresses associated with all of the .com domains. In most cases, Network Solution’s DNS servers contain records that point to the DNS server that is considered to be authoritative for each domain.

To see how all this works, imagine that you wanted to visit the www.brienposey.com website. When you enter the request into your Web browser, your Web browser forwards the URL to the DNS server specified by your computer’s TCP/IP configuration. More than likely, your DNS server is not going to know the IP address of this website. Therefore, it will send the request to the ICANN DNS server. The ICANN DNS server wouldn’t know the IP address for the website that you are trying to visit. It would however know the IP address of the DNS server that is responsible for domain names ending in .COM. It would return this address to your Web browser, which in return would submit the request to the specified DNS server.

The top level DNS server for domains ending in .COM would not know the IP address of the requested Web site either, but it would know the IP address of a DNS server that is authoritative for the brienposey.com domain. It would send this address back to the machine that made the request. The Web browser would then send the DNS query to the DNS server that is authoritative for the requested domain. That DNS server would then return the websites IP address, thus allowing the machine to communicate with the requested website.

As you can see, there are a lot of steps that must be completed in order for a computer to find the IP address of a website. To help reduce the number of DNS queries that must be made, the results of DNS queries are usually cached for either a few hours or a few days, depending on how the machine is configured. Caching IP addresses greatly improves performance and minimizes the amount of bandwidth consumed by DNS queries. Imagine how inefficient Web browsing would be if your computer had to do a full set of DNS queries every time you visit a new page.

Networking Basics: Part 4 - Workstations and Servers

2008-08-04T04:16:00.000-07:00

This article continues the Networking for Beginners series by talking about the differences between workstations and servers.

So far in this article series, I have talked a lot about networking hardware and about the TCP/IP protocol. The networking hardware is used to establish a physical connection between devices, while the TCP/IP protocol is essentially the language that the various devices use to communicate with each other. In this article, I will continue the discussion by talking a little bit about the computers that are connected to a network.

Even if you are new to networking, you have no doubt heard terms such as server and workstation. These terms are generally used to refer to a computer’s role on the network rather than the computer’s hardware. For example, just because a computer is acting as a server, it doesn’t necessarily mean that it has to be running server hardware. It is possible to install a server operating system onto a PC, and have that PC act as a network server. Of course in most real life networks, servers are running specialized hardware to help them to be able to handle the heavy workload that servers are typically subjected to.

What might make the concept of network servers a little bit more confusing is that technically speaking a server is any computer that hosts resources over a network. This means that even a computer that’s running Windows XP could be considered to be a server if it is configured to share some kind of resource, such as files or a printer.

Computers on a network typically fall into one of three roles. Usually a computer is considered to be either a workstation (sometimes referred to as a client), server, or a peer.

Workstations are computers that use network resources, but that do not host resources of their own. For example, a computer that is running Windows XP would be considered a workstation so long as it is connected to a network and is not sharing files or printers.

Servers are computers that are dedicated to the task of hosting network resources. Typically, nobody is going to be sitting down at a server to do their work. Windows servers (that is, computers running Windows Server 2003, Windows 2000 Server, or Windows NT Server) have a user interface that is very similar to what you would find on a Windows workstation. It is possible that someone with an appropriate set of permissions could sit down at the server and run Microsoft Office or some other application. Even so, such behavior is strongly discouraged because it undermines the server’s security, decreases the server’s performance, and has the potential to affect the server’s stability.

The last type of computer that is commonly found on a network is a peer. A peer machine is a computer that acts as both a workstation and a server. Such machines typically run workstation operating systems (such as Windows XP), but are used to both access and host network resources.

In the past, peers were found primarily on very small networks. The idea was that if a small company lacks the resources to purchase true servers, then the workstations could be configured to perform double duty. For example, each user could make their own files accessible to every other user on the network. If a user happens to have a printer attached to their PC, they can also share the printer so that others on the network can print to it.

Peer networks have been traditionally discouraged in larger companies because of their inherent lack of security, and because they cannot be centrally managed. That’s why peer networks are primarily found in extremely small companies or in homes with multiple PCs. Windows Vista (the successor to Windows XP) is attempting to change that. Windows Vista will allow users on traditional client/server networks to form peer groups that will allow the users and those groups to share resources amongst themselves in a secure manner, without breaking their connection to network servers. This new feature is being marketed as a collaboration tool.

Earlier I mentioned that peer networks are discouraged in favor of client/server networks because they lack security and centralized manageability. However, just because a network is made up of workstations and servers, it doesn’t necessarily guarantee security and centralized management. Remember, a server is only a machine that is dedicated to the task of hosting resources over a network. Having said that, there are countless varieties of servers and some types of servers are dedicated to providing security and manageability.

For example, Windows servers fall into two primary categories; member servers and domain controllers. There is really nothing special about a member server. A member server is simply a computer that is connected to a network, and is running a Windows Server operating system. A member server might be used as a file repository (known as a file server), or to host one or more network printers (known as a print server). Member servers are also frequently used to host network applications. For example, Microsoft offers a product called Exchange Server 2003 that when installed on a member server, allows that member server to function as a mail server. The point is that a member server can be used for just about anything.

Domain controllers are much more specialized. A domain controller’s job is to provide security and manageability to the network. I am assuming that you’re probably familiar with the idea of logging on to a network by entering a username and password. On a Windows network, it is the domain controller that is responsible for keeping track of usernames and passwords.

The person who is responsible for managing the network is known as the network administrator. Whenever a user needs to gain access to resources on a Windows network, the administrator uses a utility provided by a domain controller to create a user account and password for the new user. When the new user (or any user for that matter) attempts to log onto the network, the users credentials (their username and password) are transmitted to the domain controller. The domain controller validates the user’s credentials by comparing them against the copy stored in the domain controller’s database. Assuming that the password that the user entered matches the password that the domain controller has on file, the user is granted access to the network. This process is called authentication.

On a Windows network, only the domain controllers perform authentication services. Of course users will probably need to access resources stored on member servers. This is not a problem because resources on member servers are protected by a set of permissions that are related to the security information stored on domain controllers.

For example, suppose that my user name was Brien. I enter my username and password, which is sent to a domain controller for authentication. When the domain controller authenticates me, it has not actually given me access to any resources. Instead, it validates that I am who I claim to be. When I go to access resources off of a member server, my computer presents a special access token to the member server that basically says that I have been authenticated by a domain controller. The member server does not trust me, but it does trust the domain controller. Therefore, since the domain controller has validated my identity, the member server accepts that I am who I claim to be and gives me access to any resources for which I have permission to access.

Networking Basics: Part 5 - Domain Controllers

2008-08-04T04:15:00.000-07:00

What domain controllers are and how they fit into your network infrastructure.

In the previous article in this series, I talked about the roles of various computers on a network. As you may recall, one of the roles that I talked a little bit about was that of a domain controller. In this article, I will talk more about what domain controllers are and how they fit into your network infrastructure.

One of the most important concepts in Windows networking is that of a domain. A domain is basically a collection of user accounts and computer accounts that are grouped together so that they can be centrally managed. It is the job of the domain controller to facilitate this central management of domain resources.

To see why this is important, consider that any workstation that’s running Windows XP contains a handful of built in user accounts. Windows XP even allows you to create additional user accounts on the workstation. Unless the workstation is functioning as a standalone system or is a part of a peer network, these workstation level user accounts (called local user accounts) are not used for controlling access to network resources. Instead, local user accounts are used to regulate access to the local computer. They act primarily as a mechanism which insures that administrators can perform workstation maintenance, without the end users having the ability to tamper with workstation settings.

The reason why local user accounts are not used to control access to resources outside of the workstation that they reside on is because doing so would create an extreme management burden. Think about it for a minute. Local user accounts reside on each individual workstation. This means that if local user accounts were a network’s primary security mechanism, then an administrator would have to physically travel to the computer containing an account any time a change is needed to be made to the account’s permissions. This might not be a big deal on smaller networks, but making security changes would be extremely cumbersome on larger networks or in situations in which a change is needed to be applied globally to all accounts.

Another reason why local user accounts are not used to control access to network resources is because they don’t travel with the user from one computer to another. For instance, if a user’s computer crashed, the user couldn’t just log on to another computer and work while their computer was being fixed, because the user’s account is specific to the computer that crashed. In order for the user to be able to do any work, a new account would have to be created on the computer that the user is now working with.

These are just a few of the reasons why using local user accounts to secure access to network resources is impractical. Even if you wanted to implement this type of security, Windows does not allow it. Local user accounts can only be used to secure local resources.

A domain solves these and other problems by centralizing user accounts (and other configuration and security related objects that I will talk about later in the series). This allows for easier administration, and allows users to log onto the network from any PC on the network (unless you restrict which machines a user can login from).

With the information that I have given you so far regarding domains, it may seem that the philosophy behind domains is that, since the resources which users need access to reside on a server, you should use server level user accounts to control access to those resources. In a way this idea is true, but there is a little more to it than that.

Back in the early 1990s I was working for a large insurance company that was running a network with servers running Novell NetWare. Windows networking hadn’t been invented yet, and Novell NetWare was the server operating system of choice at the time. At the time when I was hired, the company only had one network server, which contained all of the user accounts and all of the resources that the users needed access to. A few months later, someone decided that the users at the company needed to run a brand new application. Because of the size of the application and the volume of data that the application produced, the application was placed onto a dedicated server.

The version of Novell NetWare that the company was running at the time used the idea that I presented earlier in which resources residing on a server were protected by user accounts which also resided on that server. The problem with this architecture was that each server had its own, completely independent set of user accounts. When the new server was added to the network, users logged in using the normal method, but they had to enter another username and password to access resources on the new server.

At first things ran smoothly, but about a month after the new server was installed things started to get ugly. It became time for users to change their password. Users didn’t realize that they now had to change their password in two different places. This meant that passwords fell out of sync, and the help desk was flooded with calls related to password resets. As the company continued to grow and added more servers, the problem was further compounded.

Eventually, Novell released version 4.0 of NetWare. NetWare version 4 introduced a technology called the Directory Service. The idea was that users should not have a separate account for each server. Instead, a single user account could be used to authenticate users regardless of how many servers there were on the network.

The interesting thing about this little history lesson is that although domains are unique to Microsoft networks (Novell networks do not use domains), domains work on the same basic principle. In fact, when Windows 2000 was released, Microsoft included a feature which is still in use today called the Active Directory. The Active Directory is very similar to the directory service that Novell networks use.

So what does all of this have to do with domains? Well, on Windows servers running Windows 2000 Server, Windows Server 2003, or the forthcoming Longhorn Server, it is the domain controller’s job to run the Active Directory service. The Active Directory acts as a repository for directory objects. Among these objects are user accounts. As such, one of a domain controller’s primary jobs is to provide authentication services.

One very important concept to keep in mind is that domain controllers provide authentication, not authorization. What this means is that when a user logs on to a network, a domain controller validates the user’s username and password and essentially confirms that the user is who they claim to be. The domain controller does not however tell the user what resources they have rights to.

Resources on Windows networks are secured by access control lists (ACLs). An ACL is basically just a list that tells who has rights to what. When a user attempts to access a resource, they present their identity to the server containing the resource. That server makes sure that the user’s identity has been authenticated and then cross references the user’s identity with an ACL to see what it is that the user has rights to.

Networking Basics: Part 6 - Windows Domain

2008-08-04T04:14:00.000-07:00

Discusses the anatomy of a Windows domain.

In the previous article in this series, I introduced you to the concept of domains and domain controllers. In this article, I want to continue the discussion by talking about the anatomy of a Windows domain.

As I explained in Part 5 of this article series, domains are not something new. Microsoft originally introduced them in Windows NT Server. Originally, domains were completely self contained. A single domain often housed all of the user accounts for an entire company, and the domain’s administrator had complete control over the domain and anything in it.

Occasionally though, having a single domain just wasn’t practical. For example, if a company had offices in several different cities, then each office might have its own domain. Another common scenario is when one company buys another company. In such situations, it is not at all uncommon for both companies to already have domains.

In situations like these, it is sometimes necessary for users from one domain to access resources located in another domain. Microsoft created trusts as a way of facilitating such access. The best way that I can think of to describe trusts is to compare them to the way that security works at an airport.

In the Untied States, passengers are required to show their drivers license to airport security staff before boarding a domestic flight. Suppose for a moment that I were going to fly somewhere. The security staff at the airport does not know who I am, and they certainly don’t trust me. They do however trust the state of South Carolina. They assume that the state of South Carolina has exercised due diligence in verifying my identity before issuing me a drivers license. Therefore, I can show them a South Carolina drivers license and they will let me on the plane, even though they don’t necessarily trust me as an individual.

Domain trusts work the same way. Suppose that I am a domain administrator and my domain contains resources that users in another domain need to access. If I am not an administrator in the foreign domain then I have no control over who is given user accounts in that domain. If I trust the administrator of that domain not to do anything stupid, then I can establish a trust so that my domain trusts members of the other domain. In a situation like this, my domain would be referred to as the trusting domain, and the foreign domain would be known as the trusted domain.

In the previous article, I mentioned that domain controllers provide authentication, not authorization. This holds true even when trust relationships are involved. Simply choosing to trust a foreign domain does not give the users in that domain rights to access any of the resources in your domain. You must still assign permissions just as you would for users in your own domain.

At the beginning of this article, I mentioned that in Windows NT a domain was a completely self contained environment, and that trusts were created as a way of allowing users in one domain to access resources in another domain. These concepts still hold partially true today, but the domain model changed dramatically when Microsoft created the Active Directory. As you may recall, the Active Directory was first introduced in Windows 2000, but is still in use today in Windows Server 2003 and the soon to be released Longhorn Server.

One of the primary differences between Windows NT style domains and Active Directory domains is that domains are no longer completely isolated from each other. In Windows NT, there was really no organizational structure for domains. Each domain was completely independent of any other domain. In an Active Directory environment, the primary organizational structure is known as a forest. A forest can contain multiple domain trees.

The best way that I can think of to compare a domain tree is to compare it to a family tree. A family tree consists of great grandparents, grandparents, parents, children, etc. Each member of a family tree has some relation to the members above and below them. A domain tree works in a similar manner, and you can tell a domain’s position within a tree just by looking at its name.

Active Directory domains use DNS style names, similar to the names used by Web sites. In Part 3 of this article series, I explained how DNS servers resolve URLs for Web browsers. The same technique is used internally in an Active Directory environment. Think about it for a moment. DNS stands for Domain Name Server. In fact, a DNS server is a required component for any Active Directory deployment.

To see how domain naming works, let’s take a look at how my own network is set up. My network’s primary domain is named production.com. I don’t actually own the production.com Internet domain name, but it doesn’t matter because this domain is private and is only accessible from inside my network.

The production.com domain is considered to be a top level domain. If this were an Internet domain, it would not be a top level domain, because .com would be a top level domain and production.com would be a child domain of the .com domain. In spite of this minor difference, the same basic principle holds true. I could easily create a child domain by creating another domain name that encompasses production.com. For example, sales.production.com would be considered to be a child domain of the production.com domain. You can even create grandchild domains. An example of a grandchild domain of production.com would be widgets.sales.production.com. As you can see, you can easily tell a domain’s position within a domain tree just by looking at the number of periods in the domain’s name.

Earlier I mentioned that an Active Directory forest can contain domain trees. You are not limited to creating a single domain tree. In fact, my own network uses two domain trees; production.com and test.com. The test.com domain contains all of the servers that I monkey around with while experimenting with the various techniques that I write articles about. The production.com domain contains the servers that I actually use to run my business. This domain contains my mail server and some file servers.

The point is that having the ability to create multiple domain trees allows you to segregate your network in a way that makes the most sense from a management prospective. For example, suppose that a company has offices in five different cities. The company could easily create an Active Directory forest that contains five different domain trees; one for each city. There would most likely be a different administrator in each city, and that administrator would be free to create child domains off of their domain tree on an as needed basis.

The beauty of this type of structure is that all of these domains fall within a common forest. This means that while administrative control over individual domains or domain trees might be delegated to an administrator in another city, the forest administrator ultimately maintains control over all of the domains in the forest. Furthermore, trust relationships are greatly simplified because every domain in the forest automatically trusts every other domain in the forest. It is still possible to establish trusts with external forests or domains.

Networking Basics: Part 7 - Introduction to FSMO Roles

2008-08-04T04:13:00.000-07:00

The necessity of FSMO roles.

So far in this article series, I have explained that the Active Directory consists of a forest filled with domain trees, and that the names of each domain indicate its position within the forest. Given the hierarchical nature of the Active Directory, it might be easy to assume that domains near the top of the hierarchy (or rather the domain controllers within those domains) are the most important. This isn't necessarily the case though. In this article, I will discuss the rules that individual domain controllers play within the Active Directory forest.

Earlier in this series, I talked about how domains in Windows NT were all encompassing. Like Active Directory domains, Windows NT domains supported the use of multiple domain controllers. Remember that domain controllers are responsible for authenticating user logons. Therefore, if a domain controller is not available then no one will be able to log on to the network. Microsoft realized this early on and designed Windows to allow multiple domain controllers so that if a domain controller failed, another domain controller would be available to authenticate logons. Having multiple domain controllers also allows the domain related work load to be shared by multiple computers rather than the full burden falling on a single server.

Although Windows NT supported multiple domain controllers within a domain, one of these domain controllers was considered to be more important than the others. This was known as the Primary Domain Controller or PDC. As you may recall, a domain controller contains a database of all of the user accounts within the domain (among other things). This database was called the Security Accounts Manager, or SAM database.

In Windows NT, the PDC stored the master copy of the database. Other domain controllers within a Windows NT domain were known as Backup Domain Controllers or BDCs. Any time that a change needed to be made to the domain controller’s database, the change would be written to the PDC. The PDC would then replicate the change out to all of the BDCs in the domain. Under normal circumstances, the PDC was the only domain controller in a Windows NT domain to which domain related updates could be applied. If the PDC were to fail, there was a way to promote a BDC to PDC, thus enabling that domain controller to act as the domain’s one and only PDC.

Active Directory domains do things a little bit differently. The Active Directory uses a Multi master replication model. What this means is that every domain controller within a domain is writable. There is no longer the concept of PDCs and BDCs. If an administrator needs to make a change to the Active Directory database, the change can be applied to any domain controller in the domain, and then replicated to the remaining domain controllers.

Although the multimaster replication model probably sounds like a good idea, it opens the door for contradictory changes. For example, what happens if two different administrators apply contradictory changes to two different domain controllers at the same time?

In most cases, the Active Directory assumes that the most recent change takes precedence. In some situations, the consequences of a conflict are too serious to rely on this type of conflict resolution. In these cases, Microsoft takes a stand point that it is better to prevent a conflict from occurring in the first place than to try to resolve the conflict after it happens.

To handle these types of situations, Windows is designed to designate certain domain controllers to perform Flexible Single Master Operation (FSMO) roles. Essentially this means that Active Directory domains fully support multimaster replication except in certain circumstances in which the domain reverts to using a single master replication model. There are three different FSMO roles that are assigned at the domain level, and two additional roles that are assigned the forest level.

Where are the FSMO Roles Located?

For the most part, the FSMO roles pretty much take care of themselves. It is important however for you to know which domain controllers host these roles. By default, the first domain controller in the forest hosts all five roles. As additional domains are created, the first domain controller brought online in each domain holds all three of the domain level FSMO roles.

The reason why it is so important to know which domain controllers hold these roles is because hardware eventually gets old and is decommissioned. I once saw a situation in which a network administrator was preparing to deploy an Active Directory network for his company. While waiting for the newly ordered servers to arrive, the administrator installed Windows onto a junk PC so that he could begin playing around with the various Active Directory management tools.

When the new servers finally arrived, the administrator configured them as domain controllers in the already created domain rather than creating a new forest. Of course this meant that the junk PC was holding the FSMO roles for the domain in the forest. Everything worked fine until the administrator decided to remove the “junk” PC from the network. Had he properly decommissioned this server, there would not have been a problem. Being inexperienced though, he simply reformatted the machine’s hard drive. All of a sudden the Active Directory began to experience numerous problems. If this administrator had realized that the machine that he had removed from the domain was hosting the domain and forest’s FSMO roles, the problems could have been avoided. Incidentally, in a situation like this there is a way of seizing the FSMO roles from the deceased server so that your network can resume normal operations.

What are the FSMO Roles?

I will talk more about the specific functions of the FSMO roles in the next article in this series. I do however want to quickly mention what these roles are. As you may recall, I mentioned that there are three domain specific roles, and two forest specific roles.

The domain specific roles include the Relative identifier, the Primary Domain Controller Emulator, and the Infrastructure Master. Forest level roles include the Schema Master and the Domain Naming master. Below is a brief description of what these roles do:

Schema Master: maintains the authoritative copy of the Active Directory database schema.

Domain Naming Master: maintains the list of domains within the forest.

Relative Identifier Master: responsible for ensuring that every Active Directory object at a domain receives a unique security identifier.

Primary Domain Controller Emulator: acts as the Primary Domain Controller in domains containing domain controllers running Windows NT.

Infrastructure Master: the Infrastructure Master is responsible for updating an object’s security identifier and distinguished name in a cross domain object reference.

Networking Basics: Part 8 - FSMO Roles continued

2008-08-04T04:11:00.000-07:00

Continuation of the discussion of FSMO roles.

Introduction

This article will continue the discussion of FSMO roles by discussing what the various roles do, the consequences of FSMO failures, and how to determine which server is hosting the FSMO roles.

The Importance of FSMO Roles

In the previous part of this article series, I explained that Active Directory domains use multi master replication except in certain situations in which it is critically important to avoid a conflict. In those situations, Windows reverts to a single master replication model in which a single domain controller acts as the sole authority for the change in question. These domain controllers are said to hold Flexible Single Operations Master (FSMO) roles.

As I explained in Part 7 of this article series, there are five different FSMO roles. Two of these roles exist at the forest level, and three of the roles exist at the domain level. The Forest level roles include the Schema Master and the Domain Naming master, while the domain level FSMO roles include the Relative Identifier Master, Primary Domain Controller (PDC) Emulator, and Infrastructure Master.

I actually debated as to whether or not to discuss FSMO roles so early in this article series. Ultimately I decided to go ahead because FSMO roles are so important to supporting Active Directory functionality.

As I’m sure you probably know, in order to be able to function, the Active Directory requires that the DNS services are accessible and that the domain have at least one domain controller. When an Active Directory based network is initially created, the first domain controller to be brought online is almost always configured to act as the network’s DNS server. This same domain controller is also assigned all five of the FSMO roles. If other domains are created within the forest, then the first domain controller within each domain will host the FSMO roles for that domain. The forest level FSMO roles are only hosted on a single domain controller regardless of the number of domains in the forest.

I tell you this because I want to talk about what will happen if a domain controller that is hosting the FSMO roles fails. If the domain controller that contains the forest level FSMO roles fails, you are definitely going to notice the problem. It isn’t that the FSMO roles themselves are all that critical to the network’s operation, but rather that the domain controller that hosts the forest level FSMO roles is usually also hosting the DNS services, which are considered critical to Active Directory. If the DNS services were hosted on a separate server and the domains within the forest each had more than one domain controller, you probably wouldn’t even notice the failure for a while (unless you had monitoring software to alert you to the failure).

Usually, there are no immediate consequences to an FSMO role failure, but some rather strange symptoms will develop later on if the problem is not corrected. That being the case, it is important to know the signs of an FSMO role failure. It is also important for you to know how to determine which server is hosting each FSMO role. That way, if symptoms matching that of an FSMO failure occur, you can check to see which server is hosting the role that may have failed, and can then begin the troubleshooting process on that server.

The Schema Master

The Active Directory is really nothing more than a database, and like any other database, the Active Directory contains a schema. Unlike many other databases, the Active Directory’s schema is not static. There are any number of operations that require extending the schema. For example, installing Exchange Server requires the Active Directory schema to be extended. Any time that changes are made to the Active Directory schema, those changes are applied to the Schema Master.

The Schema Master is by far the most critical of the FSMO roles, so Microsoft hides it from view. If you need to find out which server is hosting the Schema Master role, then insert your Windows Server 2003 installation CD, and double click on the ADMINPAK.MSI file that’s found in the CD’s I386 directory. When you do, Windows will launch the Administration Tools Pack Setup Wizard. Follow the wizard’s prompts to install the Administration Tools pack.

When the installation process completes, close the Setup wizard and open the Microsoft Management Console by entering the MMC command at the Run prompt. When the console opens, select the Add / Remove Snap-In command from the File menu. When you do, Windows will display the Add / Remove Snap-in properties sheet. Click the Add button found on the properties sheet’s Standalone tab to reveal a list of available snap-ins. Select the Active Directory Schema snap-in from the list and click the Add button, followed by the Close and OK buttons.

Now that the snap-in has been loaded, right click on the Active Directory Schema container and select the Operations Master command from the resulting shortcut menu. You will now see a dialog box that tells you which server is acting as the forest’s Schema Master.

The Domain Naming Master

As I have already explained, an Active Directory forest can contain multiple domains. It’s the Domain Naming Master’s job to keep track of these domains. If the Domain Naming Master were to fail, then it would be impossible to create or remove domains until the Domain Naming Master comes back online.

To determine which server is acting as the Domain naming Master for the forest, open the Active Directory Domains and Trusts console. When the console opens, right click on the Active Directory Domains and Trusts container and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Domain Naming master.

The Relative Identifier

As you know, the Active Directory allows administrators to create Active Directory objects on any domain controller. The catch is that each object must have a unique relative identifier number. To prevent relative identifier numbers from being duplicated, the Relative Identifier Master allocates a pool of relative identifiers to each domain controller. When a new object is created within a domain, the domain controller that the object is being created on takes one of its relative identifiers out of its pool and assigns it to the object. When the pool is exhausted, the domain controller must contact the Relative Identifier Master for additional relative identifiers. As such, the eventual symptom of a Relative Identifier Master failure is the inability to create objects in the Active Directory.

To determine which server is acting as the Relative Identifier for a domain, open the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the Relative Identifier by looking at the properties sheet’s RID tab.

The Primary Domain Controller Emulator

Throughout this article series, I have talked about the role that the Primary Domain Controller (PDC) plays in Windows NT environments. The PDC emulator role was created to allow Active Directory domain controllers to co-exist with Windows NT domain controllers. The basic idea was that when an organization is being upgraded from Windows NT to Windows 2000 or to Windows Server 2003, the PDC is the first domain controller to be upgraded. At that point, the newly upgraded domain controller functions both as an Active Directory domain controller and as a PDC to the domain controllers that are still running Windows NT.

Today the PDC emulator role is largely irrelevant because very few organizations still use Windows NT Server. If you need to determine which server in your domain is hosting the PDC Emulator role though, you can do so by opening the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the PDC Emulator by looking at the properties sheet’s PDC tab.

The Infrastructure Master

In an Active Directory environment, a forest can contain multiple domains. Of course the implication of this is that Active Directory domains are not completely independent entities. They must occasionally communicate with the rest of the forest. This is where the Infrastructure Master comes into play. When you create, modify, or delete an object within a domain, the change will naturally be propagated throughout the domain. The problem is that the rest of the forest is not aware of the change. It’s the Infrastructure Master’s job to make the rest of the forest aware of the change.

If an Infrastructure Master server fails then changes to objects will not be visible across domain boundaries. For example, if you were to rename a user account, the user account would still appear to have its old name when viewed from other domains in the forest.

To determine which server is acting as the Infrastructure Master for a domain, open the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the Infrastructure Master by looking at the properties sheet’s Infrastructure tab.

Networking Basics: Part 9 – Active Directory Information

2008-08-04T03:34:00.000-07:00

How objects are stored in the Active Directory

In the last few parts of this article series, I talked a lot about what the Active Directory is, and how it works in regards to your network's domain controllers. You already know from the previous articles in this series that the Active Directory is essentially a database containing various objects such as user accounts and computer accounts. In this article, I want to continue the discussion by showing you how the Active Directory is structured.

If you have ever used Microsoft Access or SQL Server, then you are probably used to being able to open the database and view it in its entirety. However, none of the primary administrative tools used for managing the Active Directory will allow you to see the entire Active Directory database. Instead, Microsoft provides you with a variety of management tools that each focus on a specific area of the database. As a new administrator, the administrative tool that you will probably use the most often is the Active Directory Users and Computers console.

You can access the Active Directory Users and Computers console from any Windows Server 2003 domain controller by selecting the Active Directory Users and Computers command from the server’s Start / All Programs / Administrative Tools menu. The console itself looks something like what you see in Figure A

Figure A: The Active Directory Users and Computers console is the primary administrative tool for managing Active Directory objects.

I will later discuss the process of creating or editing Active Directory objects, meanwhile I wanted to go ahead and show you this console because it reveals a little bit the structure of the Active Directory. If you look at Figure A, you will notice that there are a number of containers, each of which correspond to a specific object type. Every object in the entire Active Directory is assigned an object type (known as an object class). Each object also has a number of attributes associated with it. The specific attributes vary depending on the object type.

For example, the Users container is filled with user accounts, which are all classified as user objects as shown in Figure B. If you were to right click on one of these user objects and choose the Properties command from the resulting shortcut menu, you would see the user objects' properties sheet, as shown in Figure C.

Figure B: The Users container is filled with user accounts, which are all classified as user objects.

Figure C: When you right click on a user object and select the Properties command from the resulting shortcut menu, you will see the user’s properties sheet.

If you look at figure C, you will see that there are fields for various pieces of information such as first name, last name, telephone number, etc. Each of these fields corresponds to a specific attribute of the individual object. Although the majority of the fields shown in the figure are not populated, in a real life situation these fields could be used to create a corporate directory. In fact, many applications are designed to extract information directly from the Active Directory. For example, Microsoft Exchange Server (Microsoft’s e-mail server product) creates a global address list that is based on the contents of the Active Directory. This global address list is used when sending e-mail messages to other users in the company.

If you look at Figure D, you can see a screen in which I performed a search on the name Hershey (my cat’s name in case you are wondering), and Outlook returned all of the Global Address List entries that contain the name Hershey. Not surprisingly there is only one result. If you look at the results portion of the window though, you can see where Outlook would display the user’s title, business phone number, and location had these fields been populated. All of this information was extracted from the Active Directory.

Figure D

If you wanted to see even more information about the user, you could right click on the user’s name and choose the Properties command from the resulting menu. Doing so would display the screen shown in Figure E. Keep in mind that this is not an administrative screen. This is a screen that any user in the company can access directly through Outlook 2007 in order to find information about other employees.

Figure E: You can view Active Directory information directly through Microsoft Outlook.

It is easy to dismiss the significance of what I just showed you. After all, Outlook is a Microsoft product, so it only makes sense that Outlook would be able to extract information from the Active Directory which is a part of another Microsoft product.

What a lot of people do not realize though, is that it is fairly easy for anyone with the appropriate permissions to extract information from the Active Directory. In fact, there are countless third party products that are designed to interact with the Active Directory. Some are even capable of storing data in dedicated Active Directory partitions.

The reason why it is possible for you or for third party software vendors to interact with the Active Directory is because the Active Directory is based on a well known standard. The Active Directory is based on a standard called X.500. The X.500 standard is basically just a common way of implementing a directory service. Microsoft is not the only company to create a directory service based on this service. Novell originally created the NetWare Directory Service based on this standard.

There is also a standard way of accessing directory service information. In an Active Directory environment, accessing directory information involves using the Lightweight Directory Access Protocol, otherwise known as LDAP. The LDAP protocol runs on top of the TCP/IP protocol.

The first thing that you need to know about the LDAP protocol is that whoever named it must have been on crack, because there is nothing lightweight about it (although it is more lightweight than the original directory access protocol, which was not designed to take advantage of the TCP/IP protocol stack). Entire books have been written on LDAP, and an in depth discussion is not really appropriate at this point in the article series.

What I will tell you is that every object in the Active Directory is refered to by a distinguished name (often abbreviated as DN). The distinguished name is based on the object’s position within the directory hierarchy. There are many different components that can go into a distinguished name, but some of the more common ones are a common name (abbreviated as CN) and a domain name (abbreviated as DC). For example, suppose that the Contoso.com domain contained an account named User1, and the account was located in the Users container. In such a situation, the distinguished name for the user account would be:

CN=User1, CN=Users, DC=Contoso, DC=com

Networking Basics: Part 10 - Distinguished Names

2008-08-04T03:32:00.000-07:00

The basics of naming objects within a directory.

In the previous part of this article series, I explained that the LDAP protocol references objects in the Active Directory by their distinguished name, and that every object in the directory has its own unique distinguished name. In this article, I want to continue the discussion by explaining how distinguished names work.

Before I Begin

Before I get started, I just want to remind you that distinguished names are not unique to the Active Directory. Microsoft built the Active Directory to take advantage of industry standards which are used by other companies such as Novell and IBM. By learning how distinguished names work, you will not only be better prepared to manage an Active Directory environment, you will also have some degree of familiarity if you are ever asked to work with a non Microsoft network operating system.

Basic Naming Rules

Distinguished names are made up of attributes, which are assigned values. A single distinguished name almost always contains multiple attribute value pairs. To see what I am talking about, let’s look at a simple distinguished name:

CN=User1, CN=Users, DC=Contoso, DC=com

In this particular example, the distinguished name is made up of four different attribute / value pairs, each of which are separated by a comma. The first attribute / value pair is CN=USER1. In this attribute / value pair, CN (which stands for Common Name) is the attribute and User1 is the value. Attributes and values are always separated by the equals sign, and attribute / value pairs are always separated from each other by commas.

Relative Distinguished Names

When you look at a distinguished name such as CN=User1, CN=Users, DC=Contoso, DC=com, one thing probably becomes immediately apparent; distinguished names can be really long. If you take a closer look at this distinguished name, you will notice that it is hierarchical. In this particular case, DC=com represents the highest level of the hierarchy. DC=Contoso represents the second level of the hierarchy. You can tell that COM and Contoso are both domains because both use the DC attribute. The domain hierarchy mimics the domain hierarchy used by DNS servers (you learned about the DNS hierarchy earlier in this series).

It is important to understand how the distinguished name hierarchy works for two reasons. First, by understanding the naming hierarchy, it becomes possible to know exactly where a particular object is located within the directory. The other reason why it is important to understand the nature of the directory hierarchy is because sometimes shortcuts are used in lieu of a full distinguished name.

To see what I am talking about, let’s take another look at our example distinguished name: CN=User1, CN=Users, DC=Contoso, DC=com. This distinguished name simply refers to a user account (more precisely known as a user object) named User1. The rest of the information in the distinguished name simply tells us the object’s position within the directory hierarchy.

If you were trying to tell another person about this object, you would probably casually refer to it as User1. Sometimes LDAP does the same thing. This is possible because it isn’t necessary to provide information about an object’s location in the hierarchy if the location is already known.

For example, if we are performing some operation on user objects located in the Users container in the Contoso.com domain, is it really necessary to explicitly state that every single object is located in the Contoso.com domain’s Users container?

In situations like this, the distinguished name is often replaced by a Relative Display Name (abbreviated RDN). In the case of CN=User1, CN=Users, DC=Contoso, DC=com, the RDN is CN=User1. The RDN is always made up of the most specific identifier. This will be the left most attribute / value pair in the distinguished name. The remaining portion of the distinguished name is known as the parent distinguished name. In this particular case, the parent distinguished name would be CN=Users, DC=Contoso, DC=com.

Before I move on, I want to mention that Microsoft tends to use a slightly different distinguished name format than some other network operating system manufacturers. As you have already seen, Microsoft’s distinguished names tend to be based on containers and domains. There is certainly nothing wrong with this format, because it does comply with RFC 2253, which sets the rules for distinguished names.

Some of the other network operating systems tend to base their distinguished name hierarchies on companies and countries rather than containers and domains. In these types of distinguished names, the attribute O is used to designate an organization (company) name, and the letter C is used to designate a country name. Using this naming convention, the distinguished name CN=User1, CN=Users, DC=Contoso, DC=com would look something like this:

CN=User1, O=Contoso, C=US

Keep in mind that the two formats both comply with RFC 2253, but they cannot be used interchangeably. Remember that a distinguished name’s job is to describe an object and its position within the directory. The reason for the two different distinguished name formats is that Microsoft structures their directory differently than some of their competitors.

Special Characters in Distinguished Names

So far you have seen that commas and equal signs have special meaning in the context of a distinguished name. There are several other characters that also have special meanings. These characters include the plus sign, the greater than and less than signs, the number sign, the back slash, and the quotation mark. I’m not going to bother covering most of these because you will rarely, if ever, have to use them in real life.

I do however want to talk about the back slash. The back slash allows you to tell an LDAP statement to ignore the following character. This allows you to store otherwise forbidden characters in your directory.

To see how this is of use, consider that full names are often expressed as last name comma first name. Even so, LDAP does not allow you to use the statement CN=Smith, John because the comma is used by LDAP to separate attribute / value pairs. If you wanted to store the value Smith, John in the directory, you could do so by making use of the back slash, as shown below:

CN=Smith\, John

In the statement above, the back slash tells LDAP to treat the comma as data rather than as a part of the command syntax. Another way to accomplish this is to surround the entire attribute value by quotation marks. Everything within the quotation marks is treated as data rather than as a part of the syntax.

There is a special rule regarding the use of the back slash within quotation marks. The back slash can only be used to force LDAP to ignore another back slash. To put it simply, if you needed to include a back slash as a part of the data, you would simply use two back slashes instead of one. Any other use of the back slash between quotation marks is considered to be illegal.

Networking Basics: Part 11 - The Active Directory Users and Computers Console

2008-08-04T03:27:00.000-07:00

The Active Directory Users and Computers console and how to use this console to manage remote domains.

Over the last several parts of this article series, I have talked a lot about the inner workings of the Active Directory. In this article, I want to switch gears and show you what all of this information has to do with running a network.

Windows Server 2003 comes with several different tools used for managing the Active Directory. The Active Directory management tool that you will use most often for day-to-day management tasks is the Active Directory Users and Computers console. As the name implies, this console is used to create, manage, and delete user and computer accounts.

You can access this console by clicking your server’s Start button and navigating through the Start menu to All Programs / Administrative Tools. The Active Directory Users and Computers option should be near the top of the Administrative Tools menu. Keep in mind that only domain controllers contain this option, so if you do not see the Active Directory Users and Computers command, make sure that you are logged into a domain controller.

Another thing that you might notice is that the Administrative Tools menu contains a couple of other Active Directory tools: Active Directory Domains and Trusts and Active Directory Sites and Services. I will be discussing these utilities in future articles.

When you open the Active Directory Users and Computers container, you will see a screen similar to the one that is shown in Figure A. As you might recall from previous articles in the series, the Active Directory is based on a forest, which contains one or more domains. Although the forest represents the entire Active Directory, the Active Directory Users and Computers console does not allow you to work with the Active Directory at the forest level. The Active Directory Users and Computers console is strictly a domain level tool. In fact, if you look at Figure A, you will notice that production.com is highlighted. Production.com is a domain on my network. All of the containers listed beneath the domain contain Active Directory objects that are specific to the domain.

Figure A: The Active Directory Users and Computers console allows you to manage individual domains

You might have noticed that I said that production.com was one of the domains on my network, and yet none of my other domains are listed in Figure A. The Active Directory Users and Computers console only lists one domain at a time for the sake of keeping the console uncluttered. Remember when I said that the Active Directory Users and Computers console is only accessible from the Administrative Tools menu if you are logged into a domain controller? Well, the domain that is listed in the console corresponds to the domain controller that you are logged into. For example, in writing this article I logged in to one of the domain controllers for the production.com domain, so the Active Directory Users and Computers console connects to the production.com domain.

The problem with this is that domains are often geographically dispersed. For example, it is fairly common for large companies to have a different domain for each corporate office. If for instance you were in Miami, Florida and the company’s other domain represented an office in Las Vegas, Nevada it would not be practical to have to travel across the country every time you needed to manage the Las Vegas domain. Fortunately, you do not have to.

Although the Active Directory Users and Computers console defaults to displaying the domain that is associated with the domain controller that you are logged in to, you can use the console to display any domain that you have rights to. All you have to do is to right click on the domain that is being displayed and then select the Connect to Domain command from the resulting shortcut menu. Doing so displays a screen that allows you to either type in the name of the domain that you want to connect to, or to click a Browse button and browse for the domain.

Just as a domain might be located far away, you might also find it impractical to log directly in to a domain controller. For example I have worked in several offices in which domain controllers were located in a separate building or too far across the facility that I was in to make logging in to a domain controller impractical for day to day maintenance.

The good news is that you do not have to be logged in to a domain controller to access the Active Directory Users and Computers console. You only have to be logged in to a domain controller to access the Active Directory Users and Computers console from the Administrative Tools menu. You can access the Active Directory Users and Computers console from a member server by manually loading it into the Microsoft Management Console.

To do so, enter the MMC command at the server’s Run prompt. When you do that, the server will open an empty Microsoft Management Console. Next, select the Add / Remove Snap-In command from the console’s File menu. Windows will now open the Add / Remove Snap-In properties sheet. Click the Add button found on the properties sheet’s Standalone tab and you will see a list of all of the available snap-ins. Select the Active Directory Users and Computers option from the list of snap-ins and click the Add button, followed by the Close and OK buttons. The console will now be loaded.

In some situations loading the console in this way may produce an error. If you receive an error and the console does not allow you to manage the domain then right click on the Active Directory Users and Computers container and select the Connect to Domain Controller command from the resulting shortcut menu. This will give you the chance to connect the console to a specific domain controller without actually having to log in to that domain controller. Doing so will allow you to manage the domain as if you were sitting at the domain controller’s console.

That technique works great if you have a server at your disposal, but what happens if your workstation is running Windows Vista, and all of the servers are on the other side of the building?

One of the easiest solutions to this problem is to establish an RDP session with one of your servers. RDP is the Remote Desktop Protocol. It allows you to remotely control servers in your organization. In a Windows Server 2003 environment, you can enable a remote session by right clicking on My Computer and selecting the Properties command from the resulting shortcut menu. Upon doing so, you will see the System Properties sheet. Now, go to the Remote tab and select the Enable Remote Desktop on this Computer check box, as shown in Figure B.

Figure B: You can configure a server to support Remote Desktop connections

To connect to the server from Windows Vista, select the Remote Desktop Connection command from the All Programs / Accessories menu. When you do, you will see a screen similar to the one that is shown in Figure C. Now, just enter the name of your server and click the Connect button to establish a remote control session.

Figure C: Windows Vista makes it easy to connect to a remote server

Networking Basics: Part 12 - User Account Management

2008-08-04T03:19:00.000-07:00

How to create a user account and some basic user account management techniques.

In the previous part of this article series, I began discussing the Active Directory Users and Computers console. Although that article explained how to connect to the domain of choice using the console, it never actually explained how to use the console for day-to-day management tasks. In this article, I will show you some basic techniques for user account maintenance.

Creating a User Account

One of the most common uses for the Active Directory Users in Computers console is to create new user accounts. To do so, expand the container corresponding to the domain that you are attached to, and select the Users container. When you do, the console's details pane will display all of the user accounts that currently exist in the domain, as shown in Figure A.

Figure A: Selecting the Users container causes the console to display all of the user accounts in the domain.

Now, right click on the Users container and select the New command from the resulting shortcut menu. When you do, you will see a submenu that gives you the choice of many different types of objects that you can create. Technically, the Users container is just a container and you can put pretty much any type of object in it. It is generally considered bad practice though to store objects other than user objects in the Users container. That being the case, select the User command from the submenu. When you do, you will see the dialog box shown in Figure B.

Figure B: The New Object – User dialog box allows you to create a new user account.

As you can see in the figure, Windows initially only requires you to enter some very basic information about the user. Although this screen asks for things like first name and last name, these are not technically required. The only piece of information that is absolutely required is the User Logon Name. Although the other fields are optional, I recommend filling them in anyway.

The reason why I recommend filling in as many fields as you can is because a user account is nothing more than an object that will reside within the Active Directory. Things like first name and last name are attributes of the user object that you are creating. The more attribute information that you fill in, the more useful the information stored in the Active Directory will be. After all, the Active Directory is a database that you can query for information. In fact, many applications work by extracting the various attributes from the Active Directory. When you have filled in the various fields, click the Next button, and you will be taken to the screen shown in Figure C.

Figure C: You will be prompted to assign a password to the new user account.

As you can see in the figure, assigning a password is fairly simple. All you really have to do is type, and retype the password. By default, the user is required to change the password at the next logon. You can prevent this behavior by clearing the User Must Change Password at Next Logon check box. There is another check box allowing you to prevent the user from changing their password at all. You also have the option of setting passwords to never expire, or disabling the account completely.

Although there is nothing overly complex about the password screen, there is one important thing to keep in mind. When you assign a password to a new user account, the password must comply with your corporate security policy. If the password that you use does not meet the requirements dictated by the applicable group policies, then the user account will not be created.

Click next and you will see a screen displaying a summary of the options that you have chosen. Assuming that everything looks good, click Finish and the new user account will be created.

Editing User Account Attributes

Earlier, I discussed the importance of filling in the various attributes as you create a new user account. You might have noticed that the screens involved in creating a new user account did not really have many attributes that you were able to fill in. However, the Active Directory contains dozens of built in attributes related to user accounts.

I am not saying that you have to go through the console and populate dozens of attributes for every single user account. There are some attributes that do come in handy. I recommend populating attributes that are related to basic contact information. In fact, some corporations create corporate directories that are based solely on information stored in these Active Directory attributes. Even if you are not interested in building applications that extract information from your Active Directory, it is still a good idea to populate the Active Directory with user contact information. For example, suppose that you need to reboot a server, and a user is still logged into an application that resides on the server. If you have the user's contact information stored in the Active Directory, then you can simply look up the user's phone number, and call the user to ask them to log out.

Before I show you how to populate the various Active Directory attributes, I want to mention that the same technique can also be used for modifying existing attributes. For example, if a female employee were to get married, she might change her last name. You could use the techniques that I am about to show you to modify the contents of the Last Name attribute.

To access the various user account attributes, simply right click on the user account of choice and select the Properties command from the resulting shortcut menu. Upon doing so, Windows will display the screen shown in Figure D.

Figure D: The user's properties sheet is used to store attribute and configuration information for the user account.

As you can see in the figure, the properties sheet's General tab allows you to modify the user’s first name, last name, or display name. You can also fill in (or modify) a few other fields such as Description, Office, Telephone Number, E-mail, or Web Page. If you are interested in storing more detailed information about the user, then check out the Address, Telephones, and Organization tabs. These tabs all contain fields for storing much more detailed information about the user.

Resetting a User’s Password

You probably noticed in Figure D that there are a lot of different tabs on the user’s properties sheet. Most of these tabs are related to the security and configuration of the user account. One thing that most new administrators seem to notice right away when exploring these tabs is that there is no option on any of the tabs to reset the user’s password.

If you need to reset a user’s password, then close the user’s properties sheet. After doing so, right click on the user account and select the Reset Password command found on the resulting shortcut menu.

Networking Basics: Part 13 - Creating Groups

2008-08-04T03:12:00.000-07:00

This article continues the Networking for Beginners series by introducing the concept of security groups.

In the previous article in this series, I showed you how to use the Active Directory Users and Computers console to create and manage user accounts. In this article, I want to continue the discussion by teaching you about groups.

In a domain environment, user accounts are essential. A user account gives a user a unique identity on the network. This means that it is possible to track the user’s online activity. It is also possible to give a user account a unique set of permissions, assign the user a unique e-mail address, and meet all of the user’s other individual needs.

Although custom tailoring a user account to meet a user’s individual needs sounds like a good idea, it isn’t really practical in a lot of cases. Setting up and managing user accounts is a time consuming task. It isn’t a big deal if you’ve only got a couple dozen users in your organization, but if your organization has thousands of users, then account management can quickly become an overwhelming burden.

My advice is that even if you manage a very small network, you should treat the small network as if it were a big network. The reason for this is that you never know when the network will grow. Using good management techniques from the very beginning will help you to avoid a logistical nightmare later on.

I have actually seen the consequences of unexpected, rapid growth in the real world. About fifteen years ago, I was hired as a network administrator for an insurance company. At the time, the network was very small. There were only a couple dozen workstations attached to the network. The woman who was in charge of the network had no prior IT experience and was thrown to the wolves, so to speak. Not having an IT background, and not knowing any better, she had configured the network so that all of the configuration settings existed on a per user basis.

At the time, this was no big deal. There weren't many users, and it was easy to manage the various accounts and permissions. Within a year there were over two hundred PCs on the network. By the time I left the company a couple of years later, there were well over a thousand people using a network that was only initially designed to handle a few dozen.

As you can imagine, the network experienced some severe growing pains. Some of these growing pains were related to hardware performance, but most were related to the inability to effectively manage that many user accounts. Eventually, the network became such a mess that all of the user accounts had to be deleted and recreated from scratch.

Obviously, rapid unexpected growth can cause problems, but you are probably wondering why in the world things became so unmanageable that all of the accounts had to be deleted so that we could “just start over”.

As I mentioned before, all of the configuration and security settings were user based. This meant that if a department manager came to me and asked me to tell him who had access to a particular network resource, I would have to look at every account individually to see whether or not the user had access to the resource. When you only have a couple dozen users, checking every account to see which users have access to something is tedious and disruptive (at the time, checking took about 20 minutes). When you’ve got a couple hundred users checking every user account can take most of the day.

Granted, the events that I just described happened well over a decade ago. As the IT industry goes, these events might as well have occurred in prehistoric times. After all, the network operating systems that were in use at the time are now extinct. Even so, the lessons learned back then are as relevant today as they were then.

All of the problems that I just described could have been prevented if groups had been used. The basic idea behind groups is that a group can contain multiple user accounts. Since security settings are assigned at the group level, you should never manually assign permissions directly to a user account. Instead, you would assign permission to a group, and then make the user a member of the group.

I realize that this might sound a little confusing, so I will demonstrate the technique for you. Suppose that one of your file servers contains a folder named Data, and that you need to grant a user read access to the Data folder. Rather than assigning the permission directly to the user, let’s create a group.

To do so, open the Active Directory Users and Computers console. When the console opens, right click on the Users container, and select the New | Group commands from the resulting shortcut menus. Upon doing so, you will see a screen similar to the one that is shown in Figure A. At a minimum, you must assign a name to the group. For ease of management, let’s just call the group Data, since the group is going to be used to secure the Data folder. For right now, don’t worry about the group scope or the group type settings. I will teach you about these settings in the next part of this series.

Figure A: Enter a name for the group that you are creating

Click OK, and the Data group will be added to the list of users, as shown in Figure B. Notice that the group’s icon uses two heads, indicating that it is a group, as opposed to the single headed icon used for user accounts.

Figure B: The Data group is added to the list of users

Now, double click on the Data group, and you will see the group’s properties sheet. Select the properties sheet’s Members tab, and click the Add button. You are now free to add user accounts to the group. The accounts that you add are said to be group members. You can see what the Members tab looks like in Figure C.

Figure C: The Members tab lists all of the group’s members

Now it’s time to put the group to work. To do so, right click on the Data folder, and select the Properties command from the resulting shortcut menu. When you do, you will see the folder’s properties sheet. Go to the properties sheet’s Security tab, and click the Add button. When prompted, enter the name of the group that you just created (Data) and click OK. You are now free to establish a set of permissions for the group. Whatever permissions you apply to the group, also apply to group members. As you can see in Figure D, there are some other rights that are applied to the folder by default. It is best to remove the Users group from the access control list to prevent any accidental contradictions of permissions.

Figure D: The Data group is added to the folder’s access control list

Remember earlier when I mentioned how much work it was to try to figure out which users had access to a particular resource? Well, when groups are in use, the process becomes simple. If you need to know which users have access to the folder, just look to see which groups have access to the folder, as shown in Figure D. Once you know which groups can access the folder, determining who has rights to the folder is as simple as checking the group’s membership list (shown in Figure C). Any time additional users need access to the folder, just add their names to the list of group members. Likewise, you can remove permissions to the folder by deleting a user’s name from the list of group members.