Configuring vSphere 4.1 VM to Host DRS Affinity Rules

VMWare vSphere's DRS (Distributed Resource Scheduler) is mainly used for load balancing virtual machines (VMs) on a cluster. While most virtualization admins will want to run DRS in fully automated mode - i.e., vSphere decides on its own which VM is assigned to which ESX Server - there may be certain instances when you would want to enforce some conditions by setting what are known as DRS Affinity Rules.

Note that while there are two types of DRS Affinity Rules, the other one being VM to VM, this article focuses on VM to Host Affinity Rules, a feature which has just been introduced in vSphere 4.1. These rules allow you to take individual VMs or Groups of VMs and assign them to individual ESX Servers or Groups of ESX Servers.

Instances wherein you would want to enforce DRS Affinity Rules

So what are some of those instances wherein you would want to dictate which VM or VMs should (or should not) be assigned to a particular ESX Server or group of ESX Servers?

Licensing Issues
Some applications running on your VMs may have licensing peculiarities such as:

    Those that require the application to be run on only one CPU; a restriction that can have complications if you have a single-CPU server along with a bunch of dual-CPU servers.
    Those that restrict the application to one specific server with a specific serial number.

Availability Requirements
You might want to prevent a group of VMs from running on particular ESX servers.

Performance Requirements
You might want to assign some VMs to your newly acquired multiple-CPU server.
How to configure VM to Host DRS Affinity Rules

Let's now proceed to see how you can keep a single VM or a group of VMs to either a single ESX server or a group of ESX servers.

Open your vSphere Client and find the cluster on which the rules will be enforced.

In the screenshot below, we'll be enforcing the rules on DRS Cluster 1, which contains four ESX servers and a bunch of virtual machines.

Right-click on the cluster in question and, in the corresponding context menu, select Edit Settings.

First, we'll create a Virtual Machines DRS Group and assign virtual machines to it.

To do that, go to the left-hand-side panel and select DRS Groups Manager. Next, go to the Virtual Machines DRS Groups panel and click that panel's Add button.

You can now select VMs that you'd like to add to your VM group.

Click the ">>" button to add the selected VMs to the VM group. Once you're done, give your group a name (e.g. vCenter-VM-Group), then click the OK button.

Back at the DRS Groups Manager, you can then create a Host DRS Group. This is the host DRS group where you'll be assigning your newly created virtual machines DRS group.

Go to the Host DRS Groups panel and click the corresponding Add button.

You'll then see a similar window as the one where you added VMs to a group (see two screenshots back). Just like what you did with the VMs, select hosts that you want to add to the host DRS group and click the ">>" button.

Note: Assigning the VM group to a host group is optional. It is possible to assign your VM group to a single host or ESX server.

Now, give the host group a name (e.g. ESX-DR-Group-1) and click the OK button.

So now you have both a Virtual Machines DRS Group and a Host DRS Group. Notice that the screenshot below shows the DRS Groups Manager tab. This is also exactly what you'll see if you select the DRS Groups Manager in the left-hand-side panel.

Create DRS Affinity Rule

You are finally ready to create your DRS Affinity Rule. Click the Rule tab and come up with a name for your rule (e.g. Pin-vCenter-VMs-to-ESX-Group-1).

Now, for the following drop-down lists, select the following items:

• Type = Virtual Machines to Hosts
• Cluster VM Group = the Virtual Machines DRS Group you created (e.g. vCenter-VM-Group)
• Cluster Host Group = the Host DRS Group you created (e.g. ESX-DR-Group-1). This is where the VM group is supposed to run.

Notice that we skipped one drop-down list. In the screenshot, it's the one that says "Must run on hosts in group". That drop-down list is where you're supposed to select the actual rule that will apply to the VM group-host group pair.

Expand that list, select the rule you wish to implement, and click OK.

That should create your VM to Host DRS Affinity Rule.

You'll see something like this (see screenshot below) in the succeeding window. You'll have to click the "+" symbol to expand the VM to Host Rule and reveal the corresponding Cluster VM Group and Cluster Host Group on which the rule will apply.

That's it. You have just created a vSphere 4.1 VM to Host DRS Affinity Rule.

ESXi 5.0 Command Line

Introduction to the new ESXCLI

ESXi 5.0 comes with a new ESXCLI command making it easy to administer your ESXi hosts from the command line.  Although the ESXCLI command in 5.0 has a similar look and feel as it's 4.x predecessor, the new command comes with an improved syntax and support for many additional namespaces.  In addition, and even more significant, is that for the first time the new ESXCLI provides a single command set that can be used for both local and remote command line administration.   

In 5.0 the ESXCLI command is a replacement for the deprecated esxcfg-* commands used in earlier release.  It's important to note that even though the esxcfg-* commands are still included with ESXi 5.0 these commands are deprecated, meaning they are no longer officially supported.  They have been left behind to help as you transition over to ESXCLI.  The esxcfg-* commands will eventually be removed in future releases.

In vSphere 5.0 the ESXCLI command set is not yet a comprehensive CLI tool.  It will take time to add all the required functionality into the ESXCLI command set.  Until that happens users will continue to augmented the new ESXCLI with the well known vicfg-*, vmware-cmd, vmkfstools, and other CLI commands.  Over time the ESXCLI command set will continually be expanded and the non-ESXCLI commands eventually phased out and deprecated.   

Why a new CLI?

A challenge longed faced by vSphere administrators has been the need to use an array of different commands to administer their hosts.  In addition, a completely different set of commands was needed when working locally on a host versus remotely through the vCLI.  The new ESXCLI command targets these challenges by establishing a single CLI command set that can be used for both local and remote host administration.  In addition to providing a single tool, the new ESXCLI command also establishes a standard that will continue to be extended and enhanced.  This standard is documented making it easy for vendors to integrate and provide customized plug-ins enabling users to also use the ESXCLI command to manage 3^rd party add-on components.

ESXCLI Command Overview

Learning to use the ESXCLI command is very easy.  The best way to start is by logging on to the ESXi shell and from the command prompt type "esxcli":

Typing the command with no options comes back with the usage screen shown above.   This method of getting command help will be familiar to people who have used ESXCLI in the 4.x release.   From this output we see the section labeled "Available Namespaces:".   Each namespace represents a category of commands, for example there is a namespace for "network" and for "storage".

Lets look at the "network" namespace to see what additional namespaces and commands are available by running the command "esxcli network":

Here we see additional namespaces for fence, firewall, IP, vSwitch, and NIC.   To see the options are under vswitch you simply type "esxcli network vswitch" (catch the pattern?).

Here we see two namespaces under vSwitch, one for working with a distributed vSwitch and another for a standard vSwitch.   Lets see what the command is to display the list of configured standard vSwitches by running "esxcli network vswitch standard":

Here we again see the additional namespaces, but in addition for the first time we see available commands.  From here we can see that in order to list the configured standard vSwitches on the host we run the command "esxcli network vswitch standard list":

I think you will agree that it wouldn't require much additional effort to further explore the ESXCLI command to identify how to add a third vSwitch or modify any of the vSwitch settings.  And remember, part of what makes ESXCLI really cool is that can be used remotely as well as locally. 

Conclusion

ESXi 5.0 comes with a new and improved ESXCLI command set.   Different from it's 4.x predecessor the new ESXCLI command supports many additional namespaces and for the first time provides a common CLI tool that can be used for both local and remote administration. 

The new ESXCLI command doesn't yet provide a comprehensive set of capabilities.  The focus for the 5.0 release is to provide a replacement for the now deprecated esxcfg-* commands.  As such in vSphere 5.0 the ESXCLI will continue to be augmented with the vicfg-, vmware-cmd and other available CLI tools.  Over time, the ESXCLI command set will be expanded and the other CLI tools deprecated.

Learning to use the new ESXCLI command is a breeze with an intuitive and easy to learn syntax.  Simply type the "esxcli" command and press enter to get started, then simply navigate through the nested namespaces until you reach the command you need.

How to Backup Fault Tolerant VMs in vSphere 4

A major benefit of deploying VMware's vSphere 4 is the additional options it offers you for business continuity and disaster recovery, such as virtual machine level backups and high availability features. vSphere 4 Essentials Plus, Advanced, and Enterprise editions all include VMware Data Recovery, and a number of third party applications (e.g. Veeam's Backup & Replication v5 , "Best of Show" @ VMworld 2010) provide even more powerful features.

A more detailed explanation of the potential of vSphere based DR solutions is beyond the scope of this article, but all the products utilise VM snapshots to enable backing up of live VMs without affecting availability:

VMware Data Recovery Snapshot Based Backup

Another major feature in vSphere 4 Advanced and higher editions is Fault Tolerance, which is intended to eliminate VM downtime in the event of a host server failure by creating a live shadow instance of the VM on another host and keeping them in "lockstep" synchronisation. The effect is similar to clustering, but since it operates at the hypervisor level it does not require any special features at the VM software level. Again it is beyond the scope of this article to discuss the advantages and disadvantages of this technology, the important thing to note here is that FT enabled VMs cannot be snapshotted.

The Problem with Backing Up FT enabled VMs

As we have already seen, all the vSphere based VM backup solutions rely on snapshot technology to image live VMs, but Fault Tolerant VMs cannot be snapshotted which therefore precludes backing them up. Unfortunately, it seems that the first time many users discover this is when trying to run their first backup of a FT VM. Depending on their backup application, it will either not allow them to create the backup job in the first place, or the job will fail shortly after starting.

It seems that this situation was exacerbated by conflicting information from VMware when vSphere 4 was originally released, at one point they said that Fault Tolerant VMs would be allowed a single snapshot for backup purposes but this feature was not included in the released version of vSphere 4.0. Subsequently they implied that it would be enabled in a later update, but despite vSphere 4.1 including some major improvements to FT it appeared that they had given up on the single snapshot feature, at least until the next major version release.

The Solution

To be completely accurate, it is still not possible to backup FT enabled VMs. What is now the commonly accepted method is in fact a workaround, as it involves disabling FT in order to allow a snapshot to be created, and then re-enabling it once the backup has completed. This means that for the duration of the backup, the Virtual Machine will no longer have the benefit of FT protection, which may be a problem for some readers. Unfortunately if that is the case, then you will have to look at alternative backup methods, i.e., either running inside the VM or at the SAN level.

It is quite simple to test the process manually in order to establish that your backup application will be able to image an FT VM; you just need to turn off Fault Tolerance for that VM. Note that you have to "turn off" rather than "disable", otherwise it still won't allow a snapshot to be created.

Turning Off Fault Tolerance

In your vSphere Client, right-click on the FT VM and select "Fault Tolerance", then "Turn Off Fault Tolerance" from the sub-menu. The "Disable Fault Tolerance" option will only stop the lockstep synchronisation, but leaves the secondary VM in place. "Turn Off" will actually disable lockstep sync and then remove the secondary VM completely, leaving you with a normal VM that can be snapshotted as usual.

Now start your backup running and if you watch the bottom "Tasks" section in the vSphere Client, you should see the snapshot being created by the backup application. Once the backup has completed, the snapshot should be removed. Once that is done you can right-click the VM again and select the "Turn On Fault Tolerance". This might take a few minutes as it has to create a secondary VM and bring it into lockstep sync with the primary, exactly the same process as when you originally enabled FT.

This process obviously isn't a practical solution for regular scheduled backups. However, it does demonstrate the steps required to allow backups of any Fault Tolerant Virtual Machine, and it will give you an idea of the potential hazards involved. The main problem has already been mentioned; the VM will not be FT protected during the backup process so a host hardware problem would cause downtime, and an error whilst turning FT on or off could leave the VM unprotected, requiring manual intervention. On a more positive note though, in my experience such problems are very rare and are unlikely to cause downtime by themselves, and whilst the VM lacks FT protection, it will still have vSphere High Availability. Therefore, should the host fail, the VM will be started on another host. It will have undergone a "dirty shutdown" so there may be some data loss or even corruption and a short period of downtime, all of which illustrates quite neatly why Fault Tolerance was an attractive option in the first place!

Automating the Procedure

Fortunately vSphere has comprehensive scripting support, allowing for the automation of any process achievable via the vSphere Client GUI, so we can use this to turn Fault Tolerance off and on when required. vSphere scripts are written in Perl, but don't worry if you have no experience of using that - William Lam of www.virtuallyghetto.com has already done the hard work for us and created a suitable script. The instructions below will show you how to implement it. However if you are using a third party application such as Veeam and have an active support agreement with the vendor, then you should contact them first to see if they have their own solution.

1. To use any scripts you first of all need to install the vSphere CLI (Command Line Interface), which you can download from the VMware website - browse to the "Downloads" section and select vSphere4, then click the "Drivers & Tools" tab. Expand the "Automation Tools & SDKs" section then download the version of the vSphere CLI that matches your vCenter installation, note that you want the standard CLI not the "PowerCLI" (the PowerCLI has similar functionality but integrates with the Windows PowerShell):
   
2. Once you have downloaded the CLI, run the file to install it. In theory, you can run the CLI on any Windows system with a network connection to your vCenter Server, but in practice it will be much easier to install it on the same system as your VM backup application. For these instructions I have assumed you will install it to the default recommended folder location, but if you choose a custom folder then just change subsequent file paths appropriately.
3. Now download the FTcli2.pl script file from http://communities.vmware.com/docs/DOC-10279 and save it to the C:\Program Files (x86)\VMware\VMware vSphere CLI\perl\bin folder.
4. If you open the Start - Programs - VMware menu you should see an entry for the "VMware vSphere CLI", with just a Command prompt icon in it. Clicking this will indeed just open a standard command prompt, but with the location changed to the vSphere CLI installation folder. At this point to simplify things in future I would recommend adding the  C:\Program Files (x86)\VMware\VMware vSphere CLI\perl\bin folder to the default folder paths list (this website explains how to do it if you don't know).
5. With the path set, you should now find you can execute your scripts from a standard Command Prompt. Try entering FTcli2.pl /? in order to see the online help listing all the options for this script. You will see that you can specify explicit or passthrough authentication. We will assume you are running it on your vCenter Server with sufficient privileges to use passthrough.
6. Now we need to test running the script with the required options to first turn off FT, and then to turn it back on again. It would be a good idea to create a test FT VM for testing these procedures rather than using a live production VM, just in case. The command to turn off FT should be something like this: ftCLI2.pl --server vcenter.domain.local --passthroughauth --operation stop --vmname MyTestFTvm , where vcenter.domain.local is the FQDN (or IP) of your vCenter Server. Enter that command at the prompt and run it, it should return some progress information, you should see the task appear in the vSphere Client, and the Fault Tolerance will be turned off for that VM.
7. In the event that the script fails to turn off FT, then the output in the Command Prompt window, or the Task Status in the vSphere Client will usually give a good indication of the cause of the problem. You may also add the --verbose option to the command which should make it return more detailed error messages.
8. The command to turn on FT should be identical to the turn off command, except with --operation create instead, so now you should be able make a test VM Fault Tolerant and then remove FT again afterwards.
9. In order to use these new script commands effectively, they need to be coordinated with the backup application. To facilitate this, you should create two batch files; open Notepad and enter your commands, starting each separate command on a new line like this:
10. The cd C:\Program Files (x86)\.... line should not be necessary if you have already added the folder location to your default system paths list, but it won't do any harm to include it anyway. This example is for turning on FT as it contains the --operation create option.
11. Now save the file to a suitable location, making sure you change the "Save as type" to "All files" and include a .bat extension at the end of the file name. This tells Windows that it is a batch file, so the commands in it should be executed:
12. Repeat steps 9-11 but replace create with stop in order to create a batch file to turn off FT for your VM.
13. Now you have your two batch files. In the future, all you should have to do is change the --vmname MyTestFTvm option to match the name of your FT VM as shown in the vSphere Client.

Scheduling your Fault Tolerant VM Backups

The first step for every scheduled FT VM backup needs to be turning off Fault Tolerance, so you can use the Windows Task Scheduler to create a scheduled task to run your batch file at the appropriate time. The Windows Task Scheduler in Windows 2008 Server is quite different to use from the old Windows 2003 Server version but the end result is the same; this website has a good guide to the 2003 version, and this site explains the new 2008 version.

Note that when you create your task, you can specify what Windows user account it should run under. If you are using the passthrough authentication option, it is essential that you specify an account that has sufficient rights on your vCenter Server to change the Fault Tolerance settings for the VM. Configure the task to run at a suitable time and frequency for your backup schedule.

Next you need to create a backup job for your FT VM, just like any other VM backup, but you should schedule it to run at a suitable period after the "Turn Off FT" task to ensure it has time to complete that before starting the backup, otherwise it will fail. Usually I find allowing a delay of 15 minutes is ample, but you should be able to confirm what is best for your system with some testing. Setting the time for reactivating Fault Tolerance is harder because the duration of the backup job may be quite variable from day to day - set it too early and the task will fail, whilst making it too late will leave your VM unprotected for longer than necessary. The best option, which most backup applications support, is to use the option in the backup job properties to run a command after the job has completed:

My Network Places

My Network Places is the utility for browsing network resources (places) in Microsoft Windows ME, Windows 2000 and newer Windows operating systems. Network resources include:

• shared file folders on other computers
• networked local printers
• Web links (URLs)

My Network Places can be accessed from the Windows Start menu (or through My Computer). Launching My Network Places causes a new window to appear on the screen. Through this window, you can add, search for and remotely access these network resources.
My Network Places replaces the "Network Neighborhood" utility found in Windows 98 and older Windows operating systems. My Network Places also offers additional functionality not available through Network Neighborhood.

Searching for Network Resources

Network browsing is likely the feature of My Network Places you will use most often. Through My Network Places, Windows can automatically search for shared network files, printers and other resources present on your local network.
For example, many people use My Network Places to confirm that each computer set up on their home network can "see" all the other computers.
To browse a list of available network resources, choose the "Entire Network" option in the left-hand pane of My Network Places. Then, in the right-hand pane, several options may appear for the kinds of networks available to browse. Choose the "Microsoft Windows Network" option to browse resources available locally.
Each local computer found in My Network Places will be listed under its Windows workgroup name. In home networking, all computers should be set to use the same Windows workgroup, otherwise they will not all be accessible through My Network Places.

Add a Network Place

The "Add a network place" option can be found on the left-hand size of the My Network Places control window. Clicking this option brings up a Windows "wizard" that guides you through the steps to define a network resource. Here you can specify the location of the resource by entering a Web link (URL) or a remote computer / folder name in the Windows UNC format.
The Add a Network Place wizard allows you to give descriptive names to the resources you add. When finished with the wizard, an icon similar to a Windows shortcut icon appears in the resource list.
Along with the resources you manually add to My Network Places, Windows will sometimes automatically add other resources to the list. These are places on the local area network (LAN) you frequently access.

Removing Network Places

Removing a network resource from the My Network Places list works as in Windows Explorer. The icon representing any network resource can be deleted as if it were a local shortcut. During a delete operation, no action is taken on the resource itself.

View Network Connections

The My Network Places task pane contains an option to "View network connections." Choosing this option launches the Windows Network Connections window. This is technically a separate feature from My Network Places.

My Network Places - Summary

My Network Places is a standard feature of Windows starting in Windows ME and Windows 2000. My Network Places allows you to find network resources. It also supports creating descriptively-named shortcuts for network resources.
My Network Places can be a useful troubleshooting tool in situations where two local networked devices cannot communicate with each other. Resources that don't appear in the Microsoft Windows Network are likely networked improperly. Resources will not appear in My Network Places for any of the following reasons:

• firewall interference
• workgroup naming
• TCP/IP address settings
• other Windows software settings

The next page explains these and other Windows sharing issues in more detail.

Appropriately Name Windows Workgroups and Domains

Each Windows computer belongs either to a workgroup or a domain. Home networks and other small LANs utilize workgroups, whereas larger business networks operate with domains. Choosing proper workgroup and/or domain names is essential to avoiding technical problems in networking Windows computers. Ensure your workgroups and/or domains are named appropriately according to the following rules.

• Ensure each workgroup and domain name is no longer than 15 characters.
  
  
• Ensure no workgroup or domain name contains spaces. Windows ME and earlier versions of Windows do not support workgroups or domains with spaces in their name.
  
  
• Whenever possible, ensure all computers on the LAN use the same workgroup/domain name. Using common workgroups/domains makes it easier to browse the network and avoids some security complications when sharing files. Note that the default workgroup name in Windows XP is "MSHOME" but in older versions of Windows is "WORKGROUP".
  
  
• Ensure the name of the workgroup/domain is different from the name of any computer on that network.
  
  
• Avoid special characters in workgroup and domain names. Whenever possible, do not use any of the characters when naming Windows workgroups and domains: / \ * , . " @
  
  
• For simplicity, avoid using lower-case letters in workgroup or domain names.
  
  
• The workgroup name need not match the network name (SSID) on a Wi-Fi LAN.

To set or change workgroup/domain names in Windows XP, right-click on My Computer or open the System icon in Control Panel, then choose the Computer Name tab and finally, click the Change... button to access the workgroup/domain name fields.
To set or change workgroup/domain names in Windows 2000, open the System icon in Control Panel and choose the Network Identification tab, then click the Properties button.
To set or change workgroup/domain names in older versions of Windows, open the Network icon in Control Panel and choose the Identification tab.

Appropriately Name Networked Windows Computers

When setting up a peer-to-peer Windows network, each computer name must be configured properly. Computers having names that violate Windows guidelines may, for various technical reasons, fail to network with their peers on the LAN. Ensure your computers are named appropriately according to the following rules:

• No two computers can possess the same computer name. Ensure all computer names are unique.
• Ensure each computer name is no longer than 15 characters.
• Ensure no computer name contains spaces. Windows ME and earlier versions of Windows do not recognize computers having space characters in their name.
• Avoid special characters in computer names. Whenever possible, do not use any of these characters when naming Windows computers: / \ * , . " @
• Avoid using lower-case letters in a computer name whenever possible. On Windows Vista, the case of letters (upper or lower) is ignored. Older versions of Microsoft Windows, however, treat computer names as case sensitive. Entering computer names in all upper case is recommended to avoid possible name conflicts that would prevent Windows computers from identifying each other.

To set or change a computer name on Windows XP, right-click on My Computer or open the System icon in Control Panel, then choose the Computer Name tab.
To set or change a computer name on Windows 2000, open the System icon in Control Panel and choose the Network Identification tab, then click the Properties button.
On older versions of Windows, open the Network icon in Control Panel and choose the Identification tab.

Upgrading Windows Vista Ultimate to Windows 7 Ultimate

Windows 7 is the next generation of operating system due from Microsoft and it is still working on a planned release for early 2010 which would be three years after the release of Windows Vista.
This article is a complete walk through on the steps taken to upgrade your Windows Vista Ultimate installation to Windows 7 Ultimate edition.
[NOTES FROM THE FIELD] – It is important to note that Windows 7 is only in beta release at the present time. The version of Windows 7 that I am using for this walk through is Windows 7 Ultimate edition, build 6.1.7000.

Because the content is still under development and in beta release it is a preliminary tutorial and is subject to change upon the final release of this new version of Windows.

One of the first aspects to consider when doing an in-place upgrade is to make sure you back up any data on the system that you must preserve. While 99.99% of the time an in-place upgrade of supported hardware and pre-installed software will allow the operating system upgrade to go smoothly there is no point in risking critical data by skipping a step.

[NOTES FROM THE FIELD] – How to back up a PC is a very good write up that can be found on the Microsoft website that breaks down backing up PCs running Windows Vista as well as Windows XP.

Other important things to remember when contemplating an in-place upgrade:

•     You need to be running Windows Vista with Service Pack 1. According to the information on the Microsoft Website I referenced, if you don't have Service Pack 1 installed you will not be able to perform the in upgrade to Windows 7.

•     In-place upgrades are the preferred installations when you want to preserve your settings and other data, currently installed programs, etc.

•     In-place upgrades will work when you're upgrading from "like" installations such as from a 32-bit version of Windows Vista to a 32-bit version of Windows 7, or from 64-bit version to 64-bit version.

•     In-place upgrades need to be from the same Windows language. You can perform an in-place upgrade from Windows Vista (English) to Windows 7 (English); if you were running a localized version of Windows Vista for another language and attempted to install Windows 7 (English) the installation routine would fail.

[NOTES FROM THE FIELD] – In most cases, when an in-place upgrade is halted because one of the conditions above is not met, the installation routine will generally offer you the ability to do a custom installation which could be a clean install or if the disk space is available on another volume, a dual / multi-boot configuration.

The Windows Vista upgrade options from prior installations of Windows XP and Windows 2000 are shown on the Microsoft website on the Get Windows Vista: Upgrade options page which shows you which installations allow an in-place upgrade and on which ones you'll need to perform a clean install.

At the time I was writing this article I was unable to find formal upgrade paths from Windows Vista to Windows 7 anywhere on the Microsoft website. I come to expect that as Windows 7 is in beta release and all of the final coding hasn't been formalized as of yet.

Informally we already know from my Upgrading Windows XP Professional SP3 to Windows 7 Ultimate (beta build 7000) article that presently you can only perform an actual in-place upgrade from Windows Vista to Windows 7.

I am speculating at this point but I presume that the upgrade paths from Windows Vista to Windows 7 would mirror those as outlined at Get Windows Vista: Upgrade options page where Windows XP takes the place of Windows 2000 and Windows Vista takes the place of Windows XP in the table (as applicable).

Setting the Stage

Once you have verified that your operating system can handle the in-place upgrade you can boot into that operating system and get started.

For this walk through we are going to upgrade our Windows Vista Ultimate Edition service pack 1 virtual machine to Windows 7 Ultimate beta build 7000.

[NOTES FROM THE FIELD] – The system in use has been configured with a user account that does not have a password set for it. Because of this, some of the steps in the walk through will not require a log on for that reason when it otherwise should.

Once the guest OS is up and running we would insert the Windows 7 DVD to start the installation

Depending on how the autorun parameters are set up on your system you may see the AutoPlay dialog box come up or the installation routine may just begin.

Additionally, depending on how your User Account Control (UAC) settings are configured for the system, you may be presented with a prompt to allow setup.exe to run.

In that situation you would select the ALLOW action which would kick off the installation routine as shown below.

You would choose "Install now" to continue which allows setup to begin copying the needed temporary files to the system. During this process what is displayed on the screen will change a couple of times.


Once the file copy is completed you'll be prompted as to whether or not you'd like to go online to get any needed updates that would be required for the installation.





[NOTES FROM THE FIELD] – While this is an optional activity it is highly recommended.

For obvious reasons, an active internet connection will be needed throughout certain parts of the upgrade installation in order for it to be successful.

For our walk through we will choose the option to get the updates.

Once the option to get the updates is selected, setup searches for any applicable installation updates and then downloads them for use during the remainder of the installation routine.
The next page of setup is the license terms page where you would agree to the terms of the software as outlined by choosing the "I accept the license terms" check box and select NEXT.





[NOTES FROM THE FIELD] – You must agree to the license terms, otherwise the setup routine is forced to abort.

To Upgrade or to not upgrade

The next screen asks you which type of installation that you want. You have the option here to choose Upgrade which would perform an in-place upgrade of the operating system or a Custom (advanced) installation which would allow you to choose other options with respect to the installation.
For the most part, choosing anything other than Upgrade is going to force the installation routine to install Windows cleanly to another volume in which case you would need to reinstall all of your applications and settings.
For the purposes of this walk through we are going to choose the Upgrade option.
Once you choose which type of installation that you want the compatibility report that ran on the system earlier will be displayed as shown below (it will also be available on the desktop to review after the upgrade completes).
You can review the information and choose next to continue forward.


The next part of the process occurs without a lot of intervention.
The Upgrading Windows screen appears which shows you the active part of the process in bold from a list of steps that are in progress. You'll notice there and in the Gathering files, settings and programs sections that there is some addition detail about where you are in the process shown near the bottom of the activity window (in the case of the second image below that would be Gather systems files and settings (3522 of 11548 gathered)).



The next segment of the installation is where setup expands the installation files and setup continues.
Part of the way through this part of the process the setup routine will reboot the computer.

[NOTES FROM THE FIELD] – When the system restarts you want to make sure you are not doing anything with the keyboard if your system is set to check the DVD drive for a boot device; otherwise you'll hit a key and then begin booting from the DVD which starts the setup process all over from the beginning.
If you should accidentally do this you can fix it by power cycling the system and letting the routine restart from where it left off which it will do if you do not hit the keys on the keyboard on the next cycle.

After the first reboot

Once this reboot cycle gets past the "Press any key" screen you'll notice the first Windows 7 splash screens. The first will be black and show the "Windows Flag Logo" and the screen will indicate "Starting Windows"

The very next screen to appear would be a Upgrading Windows splash screen as the installation routine goes back to where it left off, expanding additional files, rebooting the system again (at least one additional time); it will also install additional features and an updates that had been downloaded as parts of earlier processes.
After this step an additional reboot occurs and the setup routine completes the in-place upgrade by migrating saved files settings and programs and reboots the system one final time.



On the last restart the setup routine gets your system ready for first use and brings you in to the product key screen where you would enter in you 25 character key.
You can clear the check box if you do not want to automatically activate Windows the next time you are online but if you take this action you will be prompted over the next 30 days to do so.
For the purposes of this walkthrough we are going to enter a key and leave that check box set.
After the key is entered the next stage is to allow you to set up how the system should be set to use Windows Update and how to perform other default actions and behavior for your system. These are options as to whether to defer any configuration at the time or to make the decision to install important updates only (which are just the security updates and other important ones for the Windows operating system as designated on the Windows Update site).
What is generally recommended is to select the Use recommend settings option which will configure the system to leverage Windows Update to automatically download and install updates as well as to configure the default browsing behavior of the system to be more controlled and secured so as to allow for a safe browsing experience. Additionally this option automatically has the operating system check online for solutions to encountered problems.
For the purposes of this walkthrough we are going to use the recommended settings option.



The next screen you'll arrive at is the Review your time and date settings page where you would check to make sure the system's time and time zone are correct. You would press NEXT to continue past this point.
After you make any needed changes to the time or the time zone you'll have to choose how your network behaves by default by choosing from one of the three network settings as presented on the Select your computer's current location page.
For our walkthrough we are going to choose Home network.



[NOTES FROM THE FIELD] – If you choose Home you may see the configuration being made and part of this configuration setup prepares your system to participate in a HomeGroup.

Once the network location has been set the option to join the HomeGroup will be present; you do not need to do this if you do not wish to configure the network for this type of use or to join an existing HomeGroup and the option to choose SKIP is presented.
From there the finalizing steps are completed and the desktop is shown.



The system is completely upgraded to Windows 7 and all of your configuration settings and applications are ready to be used.
This concludes my walk through tutorial of Upgrading Windows Vista to Windows 7 Ultimate (beta build 7000). I hope you found it informative.

Changes to the Security Center in Windows 7

The Windows Security Center made its debut in Windows XP SP2.  As you may recall, SP2 was designed to correct some of Windows XP's chronic security problems. Although SP2 did its job at least to some extent, many IT professionals saw the Security Center largely as a public relations stunt. After all, Microsoft proudly proclaimed that the Security Center contained code that was originally intended for Windows Vista, but yet the Security Center didn't really do much other than confirming that certain security settings (such as the Windows Firewall) were enabled.

When Vista was released, the Security Center looked a lot like the Windows XP version, but there was at least some stuff going on behind the scenes. The Security Center not only monitors the state of various security mechanisms, but it can use that information to assess the machine's health when Network Access Protection is being used.

With that in mind, you might be surprised to learn that the Security Center does not exist in Windows 7. Instead, Microsoft has replaced the Security Center with the Action Center, which you can see in Figure A.

Figure A

The Security Center has been replaced by the Action Center.

The Action Center

The first time that I heard about this change, I just assumed that Microsoft's marketing department had been at it again. After all, Microsoft has a long history of renaming features to make them sound more enticing or more useful. The change actually involves more than a simple name change though.

One of the big complaints that Microsoft received in regard to Windows Vista was that there were far too many nag screens and pop up balloons. These messages were often important, but they could be really annoying if the problem was not urgent, and the user did not want to deal with it at the moment.

Nag screens and popup balloons aren't completely going way in Windows 7, but it does seem that Microsoft has reduced their frequency. This is where the Action Center comes into play. The Action Center is a console where you can see any security or maintenance issues that need to be addressed, all in one place. The idea is that by consolidating the various alerts on a system wide basis, users can fix the various issues in one place, and on their own schedule.

If you look at the figure above, you can see that security issues are color coded. Red indicates that an issue is urgent, while orange indicates that the issue is important, but not yet critical.

At the bottom of the Action Center are Troubleshooting and Recovery links that you can use to locate and fix a problem or to revert your system to a previous state respectively.

The Action Center can actually display more information than what you see in the figure though. According to Microsoft, the Action Center consolidates alerts from ten different Windows 7 features including things like Windows Defender, Backup and Restore, and even User Account Control. Any time that one of these features produces a non critical alert, an icon will be displayed in the taskbar. Users can click on this icon at their leisure to go to the Action Center and address the issue.

The Action Center's Future

I don't have a crystal ball, nor do I have any inside information from Microsoft regarding the future of the Action Center. Even so, I have a feeling that Microsoft created the Action Center to do more than just appease users who were tired of nag screens.

Being that so much alerting information is being consolidated into one place, I think that it seems only logical that Microsoft will create some sort of monitoring tool that works specifically by looking at the Action Center of every PC in the organization.

Network Access Protection already allows Windows Server 2008 to detect Security Center issues, and perform remediation if necessary. How hard could it possibly be for Microsoft to extend Network Access Protection so that it can perform corrective action on other types of maintenance items that may be reported?

Quickly Change Screen Resolution in Windows 7

Windows 7, Microsoft's upcoming client operating system, has some nice UI improvements. Some of these were discussed in our previous articles. For example, read my upcoming New Taskbar Features in Windows 7 article.

One of these nice changes is the ability to easily and quickly change the display resolution of a Windows 7 computer. Prior to Windows 7, in Windows 2000/XP/2003, you could access the screen resolution properties through the Display applet in the Control Panel or from the Properties options on the Desktop. One click, another click, and you were there.

In Windows Vista and Windows Server 2008, although they were still 2 clicks away, these settings got deeper inside something that looked like a lame try to re-design the look of the personalization features of Windows.

In Windows 7, luckily for us, the Vista UI designers either got new brain implants, or got fired, and new client and customer-oriented designers were hired instead. Finally, something to look forward to!

Note: Remember, Windows 7 is still under development. The version I'm working with to grab screenshots from is beta build 7000, and things might (and probably will) change by RTM comes along.

To change the screen resolution in Windows 7 follow these steps:

Right-click an empty spot on your desktop and select "Screen Resolution" (now was it that hard, Vista UI designers? Was it indeed that hard?)

In the Control Panel'Appearance and Personalization'Display'Screen Resolution window, click on the "Resolution" drop-down list.

Notice how you can slide the slider up and down to the right resolution, and imagine that, you can even place it between stops to customize it to whatever resolution you want ("You can't imagine what type of technology we had to develop for this feature" duh!). Notice how the screen animation changes as well.

When satisfied, click out of the slider and click Ok.

Accept the new settings, or cancel to revert to the previous settings.

Bingo.

Fine Tuning Service’s Startup for Speed on Windows 7

If you have ever taken a look at the Service Control Manager, shown in Figure A, then you know that at any given time, Windows has dozens of services running in the background. Each of these services consumes some amount of system resources, and you can reclaim some of those resources by turning off unnecessary services. In this article, I'll show you how.

Figure A

The Service Control Manager allows you to enable and disable system services.

Before I Begin

The subject of which services are unnecessary is certainly open to debate. I have seen several different Websites that list the services that can be safely disabled in various versions of Windows. The thing that you have to remember though, is that each service provides some kind of functionality. Whenever you disable a service, you lose the functionality that it provides.

I am going to try to avoid telling you to disable services that provide commonly used functionality, even if such services can be "safely" disabled. For example, many of the lists that I have seen tell you to disable the Print Spooler service, but without it you can't print. I am also going to avoid talking about any services that are configured for a manual startup by default.

The other thing that I want to say is that you should set services to Manual, rather than disabling them completely. That way, if Windows has to use a service for some reason, it can at least start the service.

Desktop Windows Manager Session Manager

You can turn off the Desktop Windows Manager Session Manager service if you are not using the Aero desktop. This service provides services such as thumbnail view from the taskbar, and the Windows Flip3D interface.

Diagnostic Policy Service

The Diagnostic Policy Service enables the detection, of problems and provides help with troubleshooting and resolving those problems. If you aren't afraid to troubleshoot problems yourself (which is what most IT professionals do anyway), then this is one service that you can go ahead and stop.

IP Helper

The IP Helper service provides IPv6 connectivity over IPv4 networks. If you are not using IPv6 on your network, then it should be safe to stop this service.

Offline Files

The Offline Files service performs various maintenance functions on the offline file cache. Since most desktop users do not use offline files, this service is usually safe to turn off. Be sure to think twice before disabling this service for mobile users though, as many mobile users (including myself) do make use of the offline file cache.

Security Center

I debated heavily as to whether or not to include the Security Center on the list of services that you could turn off. Ultimately though, the Security Center does consume resources, and if you are only interested in speed, then disabling the Security Center will save some system resources.

The Security Center monitors and reports the machine's health status as it related to security. Some of the security mechanisms that the Security Center reports on include antivirus, anti spyware, and the Windows Firewall (among others). I can't in good faith recommend that you turn off the Security Center service, but you can get away with doing so if you are only interested in speed. This is particularly true if you have other mechanisms in place to ensure that Windows remains secure.

Themes (if you use Windows Classic Theme)

The Themes service provides management for user experience themes. You can disable this service if you are only using Windows classic themes, or if you want to stick with your current theme.

Windows Search

The Windows Search is another item that I debated including on my list. This service provides content indexing and property caching for files and messages.  Stopping this service can provide a speed boost to your machine; unless you need to perform a search. Stopping the Windows Search service doesn't keep you from being able to perform searches, but it does mean that searches will take a long time because  all of the content in the designated search location must be crawled at the time of the search.

A Guide to Windows 7 Network and Sharing Center

The Network and Sharing Center

You can access the Network and Sharing Center by opening the Windows 7 Control Panel and clicking on the Network and Internet link, followed by the Network and Sharing Center link. You can see what the Network and Sharing Center looks like in Figure A.

Figure A

This is what the Windows 7 Network and Sharing Center looks like.

As you can see in the figure above, the Network and Sharing Center looks a lot like it did in Windows Vista.  If you want to compare the two versions, then check out the Windows Vista Network and Sharing Center in Figure B below.

Figure B

This is the Windows Vista Network and Sharing Center.

The first change that I really like is the View Your Active Network option. As you can see in the figure, the Windows 7 version clearly displays which network you are connected to. In this case, it's a domain network named Production.com.

If you look a toward the bottom of the screen, you will notice a link labeled Connect to a Network. If you click on this link, Windows will display a dialog box that wells you which network you are connected to (just like the main screen does). More importantly though, this dialog box contains a change button. Clicking the Change button gives you the option of connecting to any other network connection that you have defined.

Sharing and Discovery

If you look at Figure B, you can see that the Windows Vista Network and Sharing Center listed all of your Sharing and Discovery settings on the main screen.  These settings have been moved in Windows 7. To access them, you must click the Change Advanced Sharing options.

If you look at Figure C, you can see that Windows 7 maintains three separate network profiles (Home or Work, Public, and Domain), and maintains separate sharing settings for each of the profiles. Another thing that I like about this screen is that it clearly identifies which profile Windows is currently using, so that you will know which of the sharing settings currently apply.

Figure C

Home Groups

In Windows 7, Microsoft seems to be placing a greater emphasis on peer networking, and has started to acknowledge that home networks are becoming much more common. If you look at Figure A, you will notice an option labeled Choose Homegroup and Sharing Options.

This feature isn't really all that useful on domain networks, but the basic idea behind it is that if you are connected to a workgroup, you can create a homegroup, which is used for sharing documents and other resources with other computers on the network. You can see what the HomeGroup screen looks like in Figure D.

Figure D

Homegroups make peer networking easy.

Vista Leftovers

It's still too early to know for sure what the Windows and Sharing Center will look like when Windows 7 is eventually released. At this point though, there are several elements that seem to be identical to their Windows Vista counterparts. These components include the Change Adapter Settings, Fix a Network Problem, and the Setup a New Connection or Network functions.

The Advanced Sharing Settings screen provides you with access to three separate network sharing profiles.