Now that PowerShell is the next great command shell and scripting language, you might need some help converting your VBScripts to PowerShell. Microsoft has put together a site and guide to convert scripts easily.

Check out the site here.

This week, I have to give a demo about some new products such as Exchange 2007, Longhorn and Windows Server Virtualization. The demo will include Longhorn Server Core.

Longhorn Server Core is interesting because it is a minimal version of Longhorn that has been stripped of many features. That means: no Windows Explorer, no Internet Explorer or Outlook Express and no other management tools you are so familiar with. The advantage is clear: a smaller footprint in hard disk space and memory and less patching. According to Microsoft, if Windows 2000 would have been stripped of features just as Longhorn Server Core, that would have resulted in 60% less patches.

Installation is a breeze as always. Just select the Longhorn Server Core option during installation of Longhorn. When it's finished and you logon, you get a blue background and a command prompt. Now what?

To get things done, you will have to use the command prompt or use another server and use tools such as compmgmt.msc remotely.

Before you start, you might need to configure IP. You will need to use netsh.exe for that. Some examples:

• Get the interface IDs: netsh interface ipv4 show interfaces
• Change IP configuration: netsh interface ipv4 set address name=interfaceid source=ipaddr mask=netmask gateway=gw
• Add DNS server(s): netsh interface ipv4 add dnsserver name=interfaceid address=ipofdnsserver index=x

Next, you might want to change the computer name. Use netdom.exe to do that.

If you need to register your copy of Longhorn, you will need to use the slmgr.vbs script. You can use slmgr with the -ato option to register. Other options are available to get information. Just run slmgr.vbs without parameters to get help. By the way, the slmgr.vbs tool is also available on Windows Vista.

To install extra server roles in Longhorn Server Core, use ocsetup.exe. Each role has a name. In Longhorn Beta 3, you will be able to use the oclist command to get an overview of roles that can be installed. For now, just use the info on the Longhorn Server Core blog for your experiments. Some of the available roles are DHCP, DNS, WINS, File Server, etc... IIS is not available. If you need to install a domain controller, you need to use dcpromo with an unattend file.

To give you an example of installing an extra role, I will use DHCP. To install the DHCP role, use ocsetup DHCPServerCore. After the installation finishes, you need to set the service startup to Automatic: sc config dhcpserver start= auto. Note that you need a space after start=. Now you can start the DHCP server with: net start dhcpserver. To actually manage the DHCP server, use the DHCP server management console from another machine.

Some other things you might want to do:

• Setting pagefile properties: scregedit.wsf (/PF option)
• Configuring automatic updates: scregedit.wsf (/AU option)
• Configuring error reporting: scregedit.wsf (/ER option)
• Allow terminal services remote admin connections: scregedit.wsf (with the /AR option)
• Allow remote desktop clients from older versions of Windows: scregedit.wsf (with the /CS option)
• Set time and date: use the Control Panel applet timedate.cpl (start it with control timedate.cpl)
• Set language and keyboard: control intl.cpl
• Change screen resolution: from another system, start regedit and modify HKLM\SYSTEM\CurrentControlSet\Control\Video\{GUID}\0000\DefaultSettings.Xresolution (and of course YResolution)
• Logoff from the system: use the logoff command (also use the logoff command after setting the resolution in the registry)
• Hardware: use pnputil to install PnP hardware for drivers that are not in the box

Most people will probably get a remote desktop connection to Longhorn Server Core to run the above commands but you can also use the new WS-Management (web services for management) features. Longhorn (and Vista!) contain the winrs command. That command is used to get a connection over port 80 or 443 (SSL) to another system and issue commands. Before you can use winrs, you need to configure something on the server side. On the server, you can issue the command winrm quickconfig to quickly configure the system to accept commands over port 80. Then, from another system, use something like winrs -r:servername command.

More resources:

• Longhorn Server Core blog
• TechNet Virtual Lab
• More about WS-Management

Mounting a Windows share on ESX is very easy with the smbmount command.

Before you start, create a directory where the share should be mounted. For instance, /mnt/tmp. Just issue the command:

mkdir /mnt/tmp

Then, use smbmount as follows (one line):

smbmount //<server>/<share> /mnt/tmp -o username=<domain>\\<user>,password=<password>

where

• <server>: name of the Windows server
• <share>: sharename on the server; you can also use c$, d$, ...
• <domain>: domain of the server or the servername if you use an account local to the server; note the double backslashes behind the domain or server name
• <user>: domain account or server account
• <password>: password of <user>

If you now go to /mnt/tmp, you should see the files that are in the share.

A couple of gotchas here:

• Make sure you allow outgoing SMB connections in the ESX firewall: command to do this is esxcfg-firewall --enableService smbClient
• Make sure that the Windows server does not have SMB signing policies. Even policies that state "if client agrees" should be disabled!

The last gotcha is usually causing the most trouble. When there are signing policies in effect, you will notice that mounting works perfectly. However, when you try to use the mount, you will get the error: stale NFS file handle.

Among other uses, smb mounts are handy to easily restore full vm VCB backups. After you mount the share where the backup files are located, you can use the vcbRestore command to restore the vm to your ESX box.

If your ESX box freezes after a SAN rescan with VI Client, check out this blog post.

We had this yesterday when we connected IBM DS8000 SAN luns to shiny new HP DL580 G4s.

In yesterday's post, I talked about esxRanger 3.0 and the integration of that product with VCB. Today, a colleague enabled VCB in a test environment we have running. The test environment consists of two ESX servers (DL580 G3) and just two 500GB luns from an HP EVA 5000.

To review the basics, VCB is a platform to facilitate taking backups of virtual machines. It provides a way to get to the virtual machine's disks using a fibre adapter in a Windows Server 2003 machine. Because of that, VCB needs to be installed on a physical machine running Windows Server 2003. VCB requires extra licensing and thus cost and is included in the Enterprise edition of VI3. You also need some scripts (integration scripts) that allow you to integrate VCB into your backup software. Our environment is using TSM (Tivoli Storage Manager) and scripts are provided to integrate with VCB. Basically, when you create a backup job, you run some pre and post-backup scripts to get the data onto the VCB server and to clean up afterwards. The big advantage of VCB is that it allows you to take a LAN-free backup of your virtual machines with no load on the ESX servers. Of course, it is only LAN free between the VCB and ESX server.

There are basically two types of VCB-based backups:

1. Full vm: each virtual machine file including all disks (vmdk files) are dumped to the VCB server so that your backup software can back them up
2. File mount: the virtual machine's volumes are mounted on the VCB server so that your backup software can get to the files in each volume

For a full vm backup, you need enough space on the VCB server to dump the complete contents of the virtual machine. For a file mount, you do not need any additional space.

So, in our test environment, a VCB server was setup with a single path to both our test luns. This is required as multipathing is not supported with VCB. VCB was installed, the TSM client was configured and the TSM integration scripts were installed as well.

You do not need to use your backup product and the integration scripts to test how VCB works because you can use the vcbmounter command line tool as well. This tool can be found (by default) in C:\Program Files\VMware\VMware Consolidated Backup Framework.

To create a snapshot of a full virtual machine, you can run vcbmounter with some command line options. For example:

vcbmounter -h <virtualcenterserver> -u <username> -p <password> -a ipaddr:<ip or name of vm> -r <a path you choose> -t fullvm -m san

This just creates a backup of a virtual machine with the ip address you specify behind ipaddr: to a path of your choice (-r). You need to specify the name of your VirtualCenter server and username and password because vcbmounter needs to send some instructions (such as create a snapshot) and also needs to get some information about which lun the vm uses.

Below you see a screenshot of vcbMounter's progress. I also specified another switch (-M 1) to export as a monolithic file instead of breaking up the vmdk in 2GB parts. The disk is compacted by default but not compressed.

I think it is clear from the above that you need enough disk space on the proxy to backup full virtual machines. The above backup took about 2 minutes. The vm had only 1 disk of 8GB and about 1,5GB of that disk was in use. Because this backup was compacted, you effectively only need 1,5GB of space on the proxy. If you would do this backup with vizioncore esxRanger 3.0, the file would be even smaller because they can also compress the data.

On the backup proxy, the saved files looked like this:

Instead of backing up the full vmdk, you can also mount the disk on the proxy so you can get to the files inside the virtual machine. Your backup software can then backup these files. To do a file mount, use the following command:

vcbmounter -h <virtualcenter> -u <username> -p <password> -a ipaddr:<ip or name of vm> -r <a path you choose> -t file -m san

The output of this command is:

The result in Windows looks like this:

This vm had only one volume (c:). In vcbMounter, I chose to mount the virtual machine's volumes under D:\Mount\XV401895-files. Under that folder, there were two subfolders: digits and letters. As you can see above, the letters subfolder contains a subfolder for each of the vm's volumes.

When you are done with the files in the mount point, don't forget to unmount the volumes. You do this with the following command:

vcbmounter -h <virtualcenter> -u <username> -p <password> -U <mount point>.

In the example above, my mount point is D:\Mount\XV401895. There is a file in this folder called umount.dat containing info needed to unmount the volumes.

In VirtualCenter, you will get some feedback from all the above operations in the recent tasks window:

It should be clear again that file mounts do not require any additional space on the proxy because nothing is copied to it. The virtual machine's disks are merely mounted on a Windows folder so they are there for the taking by your backup software.

Next steps for us are further testing with TSM and the integration scripts and also esxRanger 3.0.

I just attended a webinar hosted by vizioncore about their new esxRanger 3.0 and esxCharter 2.0. If you are into virtualization with VMware ESX, you should definitely check out their products.

The nice thing about esxRanger 3.0 is the integration with VMware's VCB platform. VCB as a platform provides services to get the vmdk off the ESX host using the fiber adapter of the VCB proxy (a separate physical box). Normally, when you integrate traditional backup products such as BackupExec or Tivoli Storage Manager, VCB creates a file on the proxy with a size equal to the vmdk and then dumps the vmdk data into this file. The backup software can then pick it up. What vizioncore is doing is intercepting the data as it is delivered by VCB and do their work such as compression and performing a differential backup. The advantage here is that you do not need as much storage and it is much faster.

VCB in itself does not provide restore options but esxRanger 3.0 does. It is just a matter of selecting a previous backup and specifying additional restore options. Note that the restore is done over the network, exactly because VCB does not provide a mechanism to get the backup to ESX using the fiber connection. This will probably become available in a later release of VCB although that is just my thought.

esxCharter 2.0 now works with VI3 and provides interesting performance views and reports of your entire VI3 environment (above what VirtualCenter 2.O provides). Useful reports include vmfs storage and vmdk files so you can get a nice overview of virtual machine storage. The new billback features allow you to calculate costs for virtual machines more easily to charge back for their use.

vizioncore also has a product called esxReplicator. Support for VI3 is supposedly coming Q1 2007. esxReplicator is interesting in scenarios where you want to provide something like a standby ESX server and you don't want to use features like SAN storage, HA etc... For example, a customer of ours is looking to use such a solution using two ESX Starter editions. ESX Starter only allows local storage so the virtual machines running on the primary ESX server could be replicated with esxReplicator to the backup ESX.

Of the new products, esxRanger 3.0 looks very promising because of the integration with VCB. You should compare the product with esXpress 3.0 before you make a decision. Both products work differently and both are still in beta.

Lots of things are moving in the ESX backup products space. We can only applaud that because backup is one the biggest headaches in a virtualization project, especially when you start virtualizing large workloads that handle lots of data.

Usually, VMotion works very well but today we got the following error after about 90% of the process:

A general system error occurred: Failed waiting for data. Error 16. Invalid argument

Oddly enough, this only happened for one virtual machine. We looked at the VirtualCenter logs in c:\windows\temp but did not really get any wiser. We then disabled and enabled VMotion on each host and that fixed it.

At the Exchange Server 2007 TechCenter, there is an article called Exchange Server 2007 Deployment: 10 Tips When Installing. Microsoft has tried to make the Exchange Server 2007 installation experience as easy and flexible as possible. They have largely succeeded at doing so. This does not mean you can just go ahead and run setup without thinking so read up on the technology, test it and plan, plan, plan...

From the article, a couple of things are interesting:

• You always need to install the Hub Transport role. Every mail that is sent will pass through this server. It makes journaling, rules, building ethical walls etc... much easier. In most deployments, you will put the Hub Transport and Mailbox role together on one server.
• The cluster installation process is integrated in setup. You get a checkbox in the installation wizard for the active node and one for the passive. For an overview on how to setup CCR with two nodes, check out my tutorial based on beta 2. Also check out the videos on the Exchange Team's blog.
• Exchange Server 2007 setup can be delegated to another user.
• Think about routing groups in the scenario where Exchange Server 2003 and 2007 coexist. Some more information about this can also be found here.

Check out the complete article, it is well worth the read.

Microsoft has posted details about the available editions of Exchange Server 2007. You can find them here. The Exchange Server 2007 Standard Edition is interesting because Microsoft have removed some limitations when compared to Exchange Server 2003. The most notable changes are:

• Support for five mailbox databases and storage groups (only one in Exchange 2003).
• Unlimited database sizes (16GB in Exchange Server 2003 pre-SP2, 75GB with SP2)

Besides that, the Standard Edition also supports local continuous replication (LCR). With LCR, you can have a copy of your Exchange databases on separate local storage.

If you want clustering or cluster continuous replication (CCR), you will need the Enterprise Edition. That edition also supports up to 50 mailbox databases and storage groups.

There are some changes to the CALs as well. Check the web page for more info.