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.
Memorable Names
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.
Structured Name
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.
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:
%Username
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.
%First
This variable uses the forename of the user who logs into the WDS client to install the image.
%Last
WDS will substitute the surname of the WDS client user when this variable is used.
%MAC
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 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?
|
Imagine that the company Deploy.com is a multinational organization with offices in three different countries:
San Francisco, USA New Orleans, USA Beijing, China Shanghai, China Dublin, Ireland Galway, Ireland
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:
San Francisco: USSFWPC001-USSFWPC999 New Orleans: USNOWPC001-USNOWPC999 Beijing: CHBJWPC001-CHBJWPC999 Shanghai: CHSHWPC001-CHSHWPC999 Dublin: IEDBWPC001-IEDBWPC999 Galway: IEGAWPC001-IEGAWPC999
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.
