What is the most difficult part of deploying a desktop operating system? Choosing the applications to include in an image (if any) might seem difficult, but that tends to be a pretty straightforward process because you just find the common denominator in the usage requirements and look at the licensing requirements. Choosing a deployment solution can also be straightforward. Once again, licensing comes into play and you just figure out how manual or automated the process needs to be. Believe it or not, the thing that may cause the most intense discussions in your project will be how you will name your machines. In this section we will briefly discuss naming standards for machines before looking at how you can implement that policy using WDS.
1. Developing a Naming Standard
A machine is given a computer name when it is deployed. The computer name is the name that makes the machine unique on the network, and it is this name that you as an administrator will use to manage the machine in your Windows environment, such as Active Directory, where it will be the computer object name. You could use the default random string that the Windows 7 setup provides. However, the default Windows 7 setup generated name can be a bit difficult to use when you are performing manual tasks such as network troubleshooting, security, or centralized software deployment. It is quite long and very random, offering no memorable structure, and the end user will find it difficult to communicate the name when talking to the help desk. You might want to use something that is still short enough to communicate, unique, and memorable.
This means that you will have to generate a new name. To make it memorable and unique, you will need some form of machine naming standard. This standard consists of a set of rules that will be used to name the machine.
One of the perks of working as an IT consultant is that you get to visit a wide variety of IT infrastructures over the years. Some are spectacular and allow you the opportunity to learn something new that you can reuse later in your career. Some are spectacular disasters and allow you the opportunity to learn the pitfalls that you should avoid. This also gives you the chance to see how organizations implement machine naming standards. There are many approaches and we will have a look at a few of them now.
Random Computer Names
Extreme security consultants (these are the folks who believe a demon is hiding behind every cubicle) love the idea of random computer names. The reason is that a potential attacker who is unfamiliar with a network cannot associate a user or an application with a name. That’s the theory anyway. It’s believed that social attacks are the most common type being employed at the moment. That’s where an attacker pretends to be someone that they are not and uses conversation and human observation to gain an entry point into an organization. It’s easy to associate a computer with an executive because they’re either using it in the airport (where it can be stolen) or it’s the one sitting in the very nice office. Applications can be identified using social engineering by calling into a help desk and pretending to be a salesperson and asking a few questions. The security consultant’s favored approach may delay the attacker but security by obscurity is not a defense. Education and real network security are the real mechanisms that should be employed.
The real benefit of a random computer name is that you don’t have to do anything to have one; the Windows 7 setup does this by default. Unfortunately, the name is pretty useless for human communications. Imagine an end user who needs someone on the help desk to remotely connect to their PC. The help desk may need to know the name of the machine. Some long, random name will be difficult to communicate over the phone. The user will either need to start an instant messaging session or send an email so that they can copy and paste the name. This process is not efficient.
Some organizations (typically small or medium) choose to use memorable computer names. For example, some networks are full of computers that are named after football players, past and present. Others feature computer names that are inspired by the cast of long-running cartoon shows. Such a naming convention can provide the nerdy IT department with a laugh but the HR manager might not be pleased to have a laptop that is called Grimey. Seriously, though, these computer names are memorable and they are easy to communicate. Unfortunately for those of us who might be nerds, the names are not very professional and this sort of naming standard is not scalable in larger organizations.
Named After the User
It is not unusual to see networks where the computer name follows the name of the primary user of that machine. For example, a user called Joe Elway may have a user account called JElway. The computer for this user may be called JElway-PC. The computer name is going to be unique because the username is unique. The name is easy to communicate; in fact, the help desk engineer who gets a call from a user can probably guess the name of the machine. This system may work for many organizations. Where it fails is that you cannot always predict who the end user of a PC is going to be. For example, if IT is building 2,000 PCs in a “factory” (a dedicated room or lab dedicated to the nonstop building of PCs), then they won’t know who the user will be. They just stack up PCs and those PCs are shipped out. Maybe the organization is very organized and has barcode asset tags and very tight asset control and shipping to allow this process, but this would be the exception. The username-based approach would also be inappropriate for an organization where the PC is used by many people, such as a call center, or it doesn’t have an assigned user at all, such as a kiosk.
It is possible to build a computer name using some form of algorithm that is structured, easy to communicate, meaningful, and easy to remember. It may look like a pretty random string to the uninitiated but once you know the structure (for that organization), you can read a lot of information from the computer name when you see it. The idea is to break the computer name down into a number of components. Each component describes something about the machine, such as its role or its primary location. Some part of the computer name will require a unique component. This can either be a random string or an incremental counter.
This type of computer name can be approached in many ways. Imagine a multinational organization that has two offices in Ireland, one in Dublin and one in Cork. There will be a number of Linux and Windows PCs. One naming standard may use the country (Ireland), the office location (Dublin or Cork), the operating system (Linux or Windows), and the type of machine (PC or server). For example, the first Windows machine might be called IEDBWPC001. That 10-character string tells us a lot about the machine. It is a Windows PC (WPC) in the Dublin (DB), Ireland (IE) office. There might also be a machine called IECKLPC099. That would be a Linux PC (LPC) in the Cork (CK), Ireland (IE) office. This can be expanded internationally. For example, CASFWPC125 might be a Windows PC in the San Francisco, California office. Of course, the same organization could also call a machine something like US-CA-Win-PC-125.
This is by no means a complete listing of your naming standards options. You can define a rule on your WDS server to ensure that all computers that are built by it are named according to that rule. And that is what we will discuss next.
2. Naming a Computer Using WDS
You can use an unattended answer file, created using the Windows System Image Manager (WSIM), to control the naming of a computer. You can continue to use that system with WDS by associating an unattended answer file with an installation image . The problem with that approach is that it requires various WSIM administrators to work together to implement a single naming standard. Otherwise your organization will end up with no standard at all. Alternatively, this approach can be useful because you might deliberately want to have different naming standards. For example, a university may have one or more shared WDS servers that are shared by different faculties. Each faculty could have their own naming standards and installation images. These naming standards could be implemented in the unattended answer files that are associated with the installation images. So the Computer Science faculty could have a Windows 7 image with an unattended answer file that implements their naming standard. The Humanities faculty would also have their own installation image with their own unattended answer file.
Most organizations will want something that is simpler, where a single policy that is consistent can be defined. WDS allows this by implementing a policy on a per-WDS server basis. Every machine that has an operating system deployed by a WDS server with this policy configured will be subject to the naming standard and named accordingly.
2.1. Configuring a WDS Client Naming Policy
The naming standard on a WDS server is referred to as a client naming policy. This policy is defined once per WDS server. You can do this by opening the properties of your WDS server in the WDS console and navigating to the AD DS tab. This tab, shown in Figure 1, does a little more work, which we will look at later, but for now, we are going to focus on the Client Naming Policy section.
Figure 1. The AD DS tab and the default client naming policy
WDS is configured with a client naming policy, which you can see in the Format field. The default policy is to name computers as %61Username%#. That is a code or a set of instructions that tells WDS how to build the computer name. You can find instructions for this code by clicking on the How To Specify This Format link in the dialog box. The possible variables that you can use are as follows:
This variable instructs WDS to use the username of the WDS client user as a basis for the computer name. For example, if the user helpdesk is used to log into the WDS client and initiate an installation of an image, then the %Username variable will be replaced with helpdesk. That would be rather unhelpful because all computers could end up using that as a core component of the computer name.
This variable uses the forename of the user who logs into the WDS client to install the image.
WDS will substitute the surname of the WDS client user when this variable is used.
The MAC or Ethernet address of the network adapter that is used to install the image will be substituted for this variable.
These variables could be combined. For example, if you use %First%Last and deploy an image using the Joe Elway user account, then the computer name will be JoeElway. You could also set the client naming policy to something like %First%Last-PC. The computer might then be called JoeElway-PC. That is because -PC is a constant and not a variable. The username of Joe Elway might be JElway. You could end up with JElway-PC if you set the client naming policy to %Username-PC.
Computer names are typically short. They are limited to 15 characters if you want the machine to join a domain. It is possible that you have users with very long names that would not be appropriate. You can control how many characters will be used from a variable.
For example, if you wanted to use six characters from the surname, you would enter %6Last. For example, deploying an image with a client naming policy of %1First%6Last-PC with the user Rebecca Handleman would result in a computer being called RHandle-PC.
What if Robert Handleman joins the company and tries to build a PC for himself using WDS? Computer names must be unique. Using this client naming policy his machine should also be called RHandle-PC. That will cause a problem.
A numeric counter would solve this problem by making the computer name unique. You can do this by using the %[n]# variable. This approach allows you to add an incremental counter of n digits. For example, %1First%6Last-PC-%2# will allow an incremental counter of two digits. Rebecca’s PC would be called RHandle-PC-1RHandle-PC-2. This could continue up to RHandle-PC-99. You can increase this counter by allowing for more digits. For example, a %4# variable will allow for up to 9,999 machines. and Robert’s PC would be called
The Default WDS Computer Naming Policy
The default computer naming policy in WDS is set to %61Username%#. That sets the computer name to use the first 61 characters of the user’s username. The name will be truncated to the first 15 characters of the username.
Imagine that your client naming policy is %1First%6Last-PC-%4#. That means that your computer names could be between 12 and 15 characters. This policy could cause problems if you are scripting based on computer name length or if you have third-party applications that need a predictable length of computer name. You can do this by padding the incremental counter with zeroes. For example, instead of having a counter of 1, you could have a counter of 0001. You can do this by using %0[n]#. For example, %1First%6Last-PC-%04# could give you RHandle-PC-0001 to RHandle-PC-9999. The computer name will always be a predicable length.
You have a lot of options by using and/or combining these variables to create a computer naming policy. How will WDS use it?
An Example Computer Naming Policy
A WDS server is set up in each office to deploy Windows 7 images. The head office IT department has designed a naming standard that will contain information describing the country, city, operating system (Windows or Linux), and role of each machine (PC or server). There will be up to 999 PCs in each office and the computer name must be a fixed length.
A constant (not a variable) will be used to define the description of the computer. A variable will be used to ensure that the computer name is unique. The computer naming policy will be defined on each WDS server as follows:
This means that computers built by WDS will be named as follows:
A Linux machine may be built (using some Linux deployment solution) and named as CHBJLPC001 in the Beijing office.
This computer naming policy describes the location and role of the computer while providing for a short and easily communicated computer name.
2.2. How WDS Implements the Client Naming Policy
WDS will use the client naming policy to configure the name of a computer as it is being built. For example, you could deploy a number of machines such as IEDBWPC001, IEDBWPC002, IEDBWPC003, and IEDBWPC004 using an IEDBWPC%03# computer naming policy.
If there is a %# variable, the counter will simply increment to generate the next available machine. For example, you could manually build IEDBWPC005 and join it to the domain. The next machine built by WDS won’t actually be IEDBWPC005. WDS will simply move on to IEDBWPC006 if that is available.
WDS will join the computers to a domain. The computer object that is created has an attribute called netbootGUID. WDS will store the MAC address or GUID of the machine’s hardware (physical or virtual) in this attribute. This means that the computer name is linked to the hardware, as long as the MAC/GUID does not change or the computer object is not removed.
You could decide to rebuild IEDBWPC002 by deploying an image to it using WDS. WDS will determine the MAC or GUID of the machine. If that value is found in an existing computer object’s netbootGUID, WDS will know to reuse the computer name.
This functionality makes the most of the available numbers you can use in a computer name and links a computer name to hardware. This can be very useful. You may implement a software distribution or computer management solution that is based on computer name. A user can rebuild their PC and still retain the same management policies because WDS will reuse their old computer name if the MAC/GUID is unchanged.