Part 2 - Preparing for deployment

At this point, you should have done all of the analysis for your new network infrastructure and answered all of the issues raised in last month’s guide. You have a fairly good idea of what things are going to look like when you’ve finished your project and have a rough idea of how you’re going to build it. And if you haven’t already ordered your server and network hardware, you’re about to.
In many cases, waiting for the hardware  to arrive can take longer than what your deployment will take. However, this doesn’t mean that you can sit around twiddling your thumbs — there’s still a lot of planning and thought that needs to be done in order to make your network easier to manage once you have your server deployed.

Get writing

One of the things that I personally hate doing is documentation — but just because you hate doing a task doesn’t mean that it doesn’t need to be done. You don’t have to be worried about documenting absolutely everything. Like with any piece of writing, there is a target audience and it’s safe to assume that the only people who will read your documentation are those that are going to have at least a rudimentary understanding of how to fix problems. However, your documentation does need to clearly show specific configuration and policy-related information for your infrastructure.

The important thing to remember with your documentation is to make sure that someone else can quickly find the information that they need to when things go wrong. Hypothetically ask yourself, “What would happen if I got hit by a bus and a hard disk on the main server failed a couple of hours later?” If your replacement can’t pick up your documentation and find the relevant information within 10 minutes, you might as well save the effort and paper.

Compulsory contents for your documentation include details on how  your network is connected, authentication mechanisms in place, what data is stored on what servers and in which location, your backup procedures, details regarding your internet connectivity, IP and telephony resources and usage and anything else that you may feel is relevant for your organisation.
In general, you should attempt to include all of the information about your infrastructure that does not change from day to day but which cannot be easily determined in the worst case scenario. For instance, detailing a list of user accounts that you’ve set up is useless — not only would you have to edit your documentation every time that you added another account, you’d have more pressing issues to look into if you couldn’t obtain this information from other sources. For similar reasons, there’s no need to document passwords — nor is it wise to do so from a security perspective.

Plan for the worst, hope for the best

Taking the above point even further, the most important document that you need to have is a disaster-recovery plan. While it’s not possible to consider every possible thing that could have an impact on your infrastructure and to develop a plan to mitigate that effect, you should plan for the rare disaster that would have the greatest impact as well as for the common events that have minor impact.

Many catastrophic scenarios generally have the same impact on your equipment — total destruction of all hardware and data at your office. Whether this destruction was caused by fire, flood or any other disaster, your recovery plan is much the same. As such, there’s no need to document a plan for each major disaster that you can think of — a ‘one size fits all’ list of instructions should suffice.

Where your disaster recovery plan does need more detail is for the minor problems that can affect your business. At minimum, you should consider scenarios involving hard disk, power supply, internet link, phone system, power, network, air conditioning and physical security failures. These issues are more likely to occur than your catastrophic disaster, and sticking to
a pre-defined plan almost always sees shorter recovery times.

Don’t forget to include a list of contacts in your disaster-recovery plan — include the contact and account details for your hardware providers in your plan, so that you have all of the information at your disposal when you need it the most.Lastly, make sure that you keep a copy of your documentation and disaster recovery plans off-site.

Conventions = convenience

In order to simplify administration, the use of various naming and addressing conventions is advisable. I have seen companies name systems based on various themes — from beer names to objects in our solar system. Each of these conventions has one major flaw — when John Doe exclaims, “There’s something wrong with this PC”, you have to determine whether he’s referring to Duff, Tiger or Heineken.

It might sound boring, but a simple convention of naming a PC after the primary user not only makes things easy to administer, it makes it easier for your users to provide more accurate reports. Citing the above example, John might now say “There’s something wrong with Jane’s PC,” in the case where you have a shared system.

When planning your internal DNS namespace, avoid the temptation to use a domain name that is able to be resolved externally. Doing so will avoid the need for you to set up separate internal and external DNS servers and will also make DNS troubleshooting simpler on your network.

Additionally, it’s a good idea to avoid  using a domain name that is closely tied to your business name if you’re setting up a Windows-based network. The main reason why is because small businesses can undergo rapid change, and it is very difficult and time-consuming to change the domain and NetBIOS names for your network. For instance, mergers, de-mergers and other name changes are more likely to occur in small businesses than large enterprise. While it is possible to change these names, the Active Directory domain rename process is extremely complicated and should not be done if it can be avoided — especially for cosmetic name changes. By picking a generic, non-public domain name, you can avoid these potential issues — ‘private.lan’ is a good generic example of this.

Lastly, if you are planning on connecting Mac systems to your network, avoid using the .local suffix. Instead of performing regular DNS lookups for the .local namespace, versions of Mac OS X earlier than 10.4 (as well as some other versions of Mac OS) will attempt to perform a multicast DNS lookup courtesy of Bonjour. The result here is that your Mac won’t be able
to resolve the names of the other hosts on your network without additional reconfiguration of your Mac. As such, use something like .lan or .internal instead.

Address This Space

Like naming conventions, addressing conventions can also make the day-to-day administration of your network simpler. Take
the time to come up with an IP addressing plan, separating blocks of your IP address range to different functions. For instance, you might use a 192.168.0.0/24 address range within your organisation. Split the range in half and use the last 128 addresses for your DHCP scope for use by client systems.

The first 128 addresses can be split a number of ways. The first 16 addresses could be reserved for network devices, including any routers, managed switches and wireless access points. The next 16 could be reserved for network printers, while the next 32 could be reserved for your servers. Any remaining addresses could be reserved for testing.

How you utilise your addresses is entirely  up to you, but if you define pools of addresses for different purposes, identifying equipment based on its IP address becomes simpler.

Patch panels preferred

While you’re waiting for your server and network equipment to arrive, ensure that your cabling is up to scratch. It’s an opportune time to arrange for a licensed data cabler to come in to your office and move those Ethernet cables that are strewn under everyone’s desk into walls and conduits, all terminating in a patch panel near where your network equipment is going to
be installed.

There are numerous benefits to doing  this, aside from the obvious aesthetic reasons. Even if cables are taped down to the floor, OH&S issues are still present. Properly installed cabling is less likely to be accidentally damaged by people kicking cables or rolling over them with their chairs.

Most importantly, if all of your network connections are brought back to a central location, not only does it become easier to secure physical access to your network (see below), it becomes easier to aggregate other services. If you have a PABX, you can utilise the same network cabling to carry both phone and data. If you plan on using VoIP, you can more easily manage the equipment that requires connection to a VoIP-enabled switch from the equipment that can be plugged into a distribution switch.Of course, keeping your patch panels neat and tidy is another matter. . .

Security from the ground up

This is also an opportune time to think about security. Always remember that there  is no guaranteed fool-proof approach to
security (of course, as soon as we make something fool-proof, a bigger fool comes along). There’s also little point in implementing security restrictions that hinder you while you’re trying to do your work.

In other words, you only need to secure what needs to be protected, and you only need to apply a certain level of security to each resource depending on how sensitive, important or costly that resource is.

Citing the example of an accounting firm that was frequently mentioned in the last article, it would be prudent to implement a basic password policy on a central LDAP-based server in order to provide single sign-on for users — after all, users find it easier to remember one complex password than 20 simple ones. Access to printers and many file shares don’t need to be secured in this case,  but shares containing the financial records for clients probably should have tighter security settings.
 
Of course, there are physical security constraints that you’d also want to consider. Many offices utilise keys and/or proximity cards to prevent physical access to certain locations — and your server room should be one of these off-limits places.
While most people don’t think that any physical connection is present with wireless networks, the underlying network model still considers the air a physical medium. Regardless, it goes without saying that implementing some form of wireless security is also required. Regardless of the type of encryption you use, you generally have two choices of authentication mechanisms to choose from — pre-shared keys (which are less secure as they are prone to brute force attack, but easy to set up) and the use of an Extensible Authentication Protocol (EAP requires considerably more effort to set up, is more secure and requires less effort for end users to use). Both options should be investigated and you should evaluate which method of authentication is better for your environment (this series will show how to configure all of the steps required in deploying EAP under both Linux and Windows environments).

Asset assessment

You should also create an asset register before your new equipment arrives. Upgrade projects such as the one that you’re about to undertake are an opportune time to take stock of the hardware and software assets that you have in your organisation.
Again, this doesn’t have to be done in anything as complex as a database — a simple spreadsheet that details hardware components and serial numbers with system names, licenses with users and/or devices and applications installed on each system is all that’s required for any small business.

A basic asset register is important to have to ensure that your business is compliant with its software licensing — and also helps you know what hardware is installed in each system without having to open up each PC. No more walking round the office looking for that TV tuner card!

When your hardware arrives

It’s always an exciting time when your new hardware arrives. I’m personally lucky enough to build around one new server every week, and I don’t think that I’ll ever get tired of taking individual components out of their boxes and installing them in the server chassis.
 
But you have to contain your excitement to an extent and make sure that you properly record the serial numbers for your components in your asset register, and that you read the instructions for installing the hardware properly. This is especially true if you purchased a brand-name server. The retention mechanisms for heatsinks in particular are often different to what you see on desktop systems, and it’s not too difficult to break things if you don’t know what you’re doing. Even the seemingly trivial task of installing memory modules should only be done after consulting the manual in order to determine which slots are best utilised.

And don’t get me started on removing some of the air baffles that direct air over the memory banks on newer servers!

When you have assembled your server,  take the time to run a few burn-in tests before starting to set things up. Utilities including Memtest86+ (for memory testing), IOmeter (for disk testing) and CPU Burn-In (for CPU and cooling-system testing) can all be used to stress-test various server subsystems, potentially revealing some problems that may have gone unnoticed for perhaps weeks after you’ve completed deployment. You should run each test for as long as you deem necessary, to be confident that the hardware subsystem being tested is working properly.

Some of these burn-in utilities will require an installation of Linux or Windows to run — which is also an opportune reason to do a pilot installation of the operating system that you plan on deploying using either the quick-start CD provided by your hardware vendor (in the case of HP and some other server builders), or your OS installation media in conjunction with supplied driver disks.

If you were planning on using Windows Small Business Server, the installation can be broken down into two distinct phases — the base Windows Server 2003 installation is done in phase one, while the Small Business Server components are installed afterward. During your test installation, there’s no need to install the SBS components — you’re only interested in verifying the installation of drivers and the execution of your burn-in tests. To back out of the installation of SBS components, simply eject your media while your system is rebooting after the Windows installation — or click on the Cancel button when you encounter the “Continuing Microsoft Windows Small Business Server” screen.

Next month’s Masterclass will start our walkthrough of setting up Microsoft Windows Small Business Server for a typical small business. If you have any questions relating  to this article (be they general or workplace-specific) you can forward them to Jarrod via masterclass@acpmagazines.com.au . A selection of questions and answers will be published on the apcmag.com web site.When your hardware arrivesIt’s always an exciting time when your new hardware arrives. I’m personally lucky enough
to build around one new server every week, and I don’t think that I’ll ever get tired of taking individual components out of their boxes and installing them in the server chassis.

But you have to contain your excitement to an extent and make sure that you properly record the serial numbers for your components in your asset register, and that you read the instructions for installing the hardware properly. This is especially true if you purchased a brand-name server. The retention mechanisms for heatsinks in particular are often different to what you see on desktop systems, and it’s not too difficult to break things if you don’t know what you’re doing. Even the seemingly trivial task of installing memory modules should only be done after consulting the manual in order to determine which slots are best utilised. And don’t get me started on removing some of the air baffles that direct air over the memory banks on newer servers!

When you have assembled your server, take the time to run a few burn-in tests before starting to set things up. Utilities including Memtest86+ (for memory testing), IOmeter (for disk testing) and CPU Burn-In (for CPU and cooling-system testing) can all be used to stress-test various server subsystems, potentially revealing some problems that may have gone unnoticed for perhaps weeks after you’ve completed deployment. You should run each test for as long as you deem necessary, to be confident that the hardware subsystem being tested is working properly.

Some of these burn-in utilities will require an installation of Linux or Windows to run — which is also an opportune reason to do a pilot installation of the operating system that you plan on deploying using either the quick-start CD provided by your hardware vendor (in the case of HP and some other server builders), or your OS installation media in conjunction with supplied driver disks.

If you were planning on using Windows Small Business Server, the installation can be broken down into two distinct phases — the base Windows Server 2003 installation is done in phase one, while the Small Business Server components are installed afterward. During your test installation, there’s no need to install the SBS components — you’re only interested
in verifying the installation of drivers and the execution of your burn-in tests. To back out  of the installation of SBS components, simply eject your media while your system is rebooting after the Windows installation — or click on the Cancel button when you encounter the “Continuing Microsoft Windows Small Business Server” screen.

Next month’s Masterclass will start our walkthrough of setting up Microsoft Windows Small Business Server for a typical small business. If you have any questions relating to this article you can ask them below.