Synchronize time throughout your entire Windows network

It is important to synchronize the time on your network and devices, Its been reviewed the different types of timing sources and looked at methods you can use to coordinate the time on your network security devices.

However, it's not enough to simply synchronize the time on your network devices—this effort should extend all the way to the desktop. Applying a single, consistent time source throughout your network can boost both network efficiency and security.

Synchronizing time on your Windows domain requires following the Active Directory domain hierarchy to find a reliable time source for your entire domain. In a Windows Server 2003 Active Directory forest, the server that holds the primary domain controller (PDC) emulator role acts as the default time source for your entire network.

Each workstation and server in this network will try to locate a time source for synchronization. Using an internal algorithm designed to reduce network traffic, systems will make up to six attempts to find a time source. Here's a look at the order of these attempts:

Parent domain controller (on-site)
Local domain controller (on-site)
Local PDC emulator (on-site)
Parent domain controller (off-site)
Local domain controller (off-site)
Local PDC emulator (off-site)
To ensure that your servers are finding the proper time, you must configure your PDC emulator to receive the time from a valid and accurate time source. To configure this role, follow these steps:

Log on to the domain controller.
Enter the following at the command line:

W32tm /config /manualpeerlist: /syncfromflags:manual

""is a space-delimited list of DNS and/or IP addresses. When specifying multiple time servers, enclose the list in quotation marks.

Update the Windows Time Service configuration. At the command line, you can either enter W32tm /config /update, or you can enter the following:

Net stop w32time
Net start w32time

If a system isn't a member of a domain, you must manually configure it to synchronize with a specified time source. Follow these steps:

Go to Start | Control Panel, and double-click Date And Time.

On the Internet Time tab, select a time server from the drop-down list, or enter the DNS name of your network's internal time source.
Click Update Now, click Apply, and click OK.

Note: It's important to make sure that any access control lists on your network allow UDP port 123 to and from systems to the selected time source. For more information, see Microsoft's Windows Time Service Tools and Settings documentation.

Five tips for deciding whether to virtualize a server.

Not all servers are suited for virtualization. Be sure you consider these possible deal-killers before you try to virtualize a particular server.

Even though server virtualization is all the rage these days, some servers simply aren’t good candidates for virtualization. Before you virtualize a server, you need to think about several things. Here are a few tips that will help you determine whether it makes sense to virtualize a physical server.


1: Take a hardware inventory
If you’re thinking about virtualizing one of your physical servers, I recommend that you begin by performing a hardware inventory of the server. You need to find out up front whether the server has any specialized hardware that can’t be replicated in the virtual world.

Here’s a classic example of this: Many years ago, some software publishers used hardware dongles as copy-protection devices. In most cases, these doubles plugged into parallel ports, which do not even exist on modern servers. If you have a server running a legacy application that depends on such a copy-protection device, you probably won’t be able to virtualize that server.
The same thing goes for servers that are running applications that require USB devices. Most virtualization platforms will not allow virtual machines to utilize USB devices, which would be a big problem for an application that depends on one.
Vendor HotSpot
Get the Most Out of Server Virtualization



Learn More »
2. Take a software inventory
You should also take a full software inventory of the server before attempting to virtualize it. In a virtualized environment, all the virtual servers run on a host server. This host server has a finite pool of hardware resources that must be shared among all the virtual machines that are running on the server as well as by the host operating system.
That being the case, you need to know what software is present on the server so that you can determine what system resources that software requires. Remember, an application’s minimum system requirements do not change just because the application is suddenly running on virtual hardware. You still have to provide the server with the same hardware resources it would require if it were running on a physical box.


3. Benchmark the system’s performance
If you are reasonably sure that you’re going to be able to virtualize the server in question, you need to benchmark the system’s performance. After it has been virtualized, the users will be expecting the server to perform at least as well as it does now. The only way you can objectively compare the server’s post-virtualization performance against the performance that was being delivered when the server was running on a dedicated physical box is to use the Performance Monitor to benchmark the system’s performance both before and after the server has been virtualized. It’s also a good idea to avoid over-allocating resources on the host server so that you can allocate more resources to a virtual server if its performance comes up short.


4. Check the support policy
Before you virtualize a server, check the support policy for all the software that is running on the server. Some software publishers do not support running certain applications on virtual hardware.
Microsoft Exchange is one example of this. Microsoft does not support running the Unified Messaging role in Exchange Server 2007 or Exchange Server 2010 on a virtual server. It doesn’t support running Exchange Server 2003 on virtual hardware, either. I have to admit that I have run Exchange Server 2003 and the Exchange Server 2007 Unified Messaging role on a virtual server in a lab environment, and that seems to work fine. Even so, I would never do this in a production environment because you never want to run a configuration on a production server that puts the server into an unsupported state.


5. Perform a trial virtualization
Finally, I recommend performing a trial virtualization. Make a full backup of the server you’re planning to virtualize and restore the backup to a host server that’s running in an isolated lab environment. That way, you can get a feel for any issues you may encounter when you virtualize the server for real.
Although setting up such a lab environment sounds simple, you may also have to perform a trial virtualization of some of your other servers. For example, you might need a domain controller and a DNS server in your lab environment before you can even test whether the server you’re thinking about virtualizing functions properly in a virtual server environment.