My wife and I just bought a new house, so naturally the first thing to be done before moving in is painting the garage floor with epoxy. :) Epoxy provides superior protection against oils, chemicals and stains by allowing them all to be wiped up easily. Plus it transforms your garage from dull and boring concrete to a beautiful space that makes one almost sad to park cars in. This is the second garage I’ve epoxied so this post is to document my experience as well as lessons learned throughout the process.

Not all epoxies are created equal, however. The $100 2-part kits you find at Home Depot and Lowes are water-based epoxies which are thin, require multiple coats, and won’t last as long as they should. I used one of these kits at my first house almost 10 years ago which turned out ok for the most part but there are areas where the epoxy pulled up from the concrete. This time I wanted something better: 100% solid epoxy. This is the premier epoxy flooring material which is much more expensive to manufacture than water-based epoxy and is also several times thicker than its off-the-shelf equivalents. The three manufacturers of solid epoxy that I considered for my project were Epoxy-Coat, Wolverine, and U Coat-It. Not only is solid epoxy several times the thickness of the water-based products, but it’s several times the price as well. You get what you pay for.

After doing hours of research and countless searches on garagejournal.com I decided on Epoxy-Coat for my project. Most people are very pleased with the results plus they recently signed a deal with Lowes who will distribute their products. While not readily available off-the-shelf in all stores, Epoxy-Coat can be special-ordered by Lowes in both full and half-kits at a price less than what you would pay direct from the MFR (the better deal is the full kit!).  As stated, a full kit can cover 500sq-ft and a half kit 250sq-ft each at 9.7dft (Dry Film Thickness). This equates to roughly 4 batches with the full kit and 2 batches with the half kit. Each full kit comes complete with a 6-gallon mixing bucket, 2 parts base coat/hardener, acid etch, squeegee, roller fill, mixing tool, gloves, paint chip flakes (3 colors), aluminum oxide (non-slip additive), and a video CD-ROM (also available on their website).

The base color and flake colors can be customized but I opted to use standard grey for the base with no flakes. Just a personal choice. If you like the confetti look and want to lay down flakes, you should also consider applying a clear coat to UV-protect the flakes which will fade over time otherwise. The clear coat will add roughly 50% to the per kit cost of your project.

Prep

Surface preparation is key and will directly correlate to the quality of floor you ultimately lay down. The garage I am working with is a 20-year old 3 car garage that has some minor surface cracking and grease stains. Luckily there was no previous sealer or that would have to be removed first. A floor can be prepped in two ways: washing/etching or diamond grinding.

Diamond grinding is what the pros do and can be done by you via a grinder rental at your local DIY store. These machines are large “walk behind” style machines with either single or dual heads. Edco is the brand that I’ve seen most recommended. The advantage of diamond grinding is that you will create a very consistent profile across the floor removing all surface imperfections and contaminants. You could also use a 4” or 7” diamond cup wheel attached to an angle grinder for small or tight areas. Either way be prepared to deal with a lot of dust. Pictured below on the right is a 7” Bosch with a dust muzzle that attaches to a shop vac.

            

Washing/etching is a more involved process that can also create a suitable profile for epoxy but requires much more elbow grease. This is the method I opted to use. First remove all loose material by sweeping/ leaf blowing. Remove surface contaminants like paint splatter using a scraper tool. Apply degreaser to oil stains and scrub with a stiff bristled brush. Wash thoroughly.

Pour the contents of the muriatic acid bottle (supplied) into a bucket and mix with 1 gallon of hot water. Pour into a plastic sprayer. Work in 10’x10’ sections spraying the acid on the floor and scrubbing with the stiff bristled brush. You should see some foaming which is the acid reacting with the concrete. Work over the entire floor and once complete, pour baking soda over the treated areas.

Triple rinse the floor with a garden hose ensuring that all materials are removed. Let the floor dry completely, depending on the outside temperature and humidity this could take a day or two. If the floor is even a little wet when you go to lay the epoxy you will have bubbles. Use a leaf blower to expedite the process. Once the floor is dry you can fill any cracks that you have with an adhesive acrylic caulk (NO SILICONE!) and a tape blade. While epoxy can be used to fill holes and cracks, it doesn’t work like you’d expect. Unless you specifically try to fill holes and cracks they may not cover completely from a normal application. Let the caulk dry completely then remove any drops or peaks along the cracks. Leaf blow the floor one more time and we’re ready to pour the epoxy.

Anti-slip additives

Epoxy-Coat sends you a bag of aluminum oxide (AO) which is a very hard glass granule looking substance that is added at the end of the application process. While AO is extremely effective, from what I’ve read, it is super hard and super SHARP. People report that a floor treated with AO is extremely hard to clean because it will literally shred your mops and rags. Squeezing a piece in the bag will cut you. If you work on your garage floor changing oil etc, guess what else it shreds? Pants, skin, elbows, kids…

I came across a product called SharkGrip made by H&C and sold by Sherwin Williams. It has the consistency of talcum powder and is mixed into the batch before it goes on the floor. Many people rave about this stuff because it adds good traction to an otherwise slippery epoxy floor plus leaves the floor cleanable and skin friendly. I opted out of using the AO and picked up a 16Oz bottle of SharkGrip for ~$15 from my local SW. They also sell a smaller 3.3Oz can that is intended to be mixed with 1 gallon of sealant/epoxy. Just to make sure, I asked Epoxy-Coat about SharkGrip and they have no issue using it with their product.

Application

Set up a mixing area and lay out all materials on a leak-proof drop cloth. Use the supplied measuring stick that has lines for where to pour A and B parts in a double or single batch. The B is the hardener which is clear, this goes in first. The base gets poured into the hardener. First mix the A base coat in its own bucket for 2 minutes with the mixing tool. This is when I added the SharkGrip. Since the A part is 2 gallons in the full kit, I poured in ~6oz of SharkGrip. Per the single batch measuring lines, this will create enough product to do a 10’x10’ area before you need to mix another batch. Add the hardener, then the base, and mix for 3 minutes. I sprinkled in an additional measure of SharkGrip at this step as well.

Pour all the mixed contents in a line on the floor at the far corner of the room. Consider which wall you will pour against because you have to first squeegee the epoxy perpendicular to the pour line to spread it out, then back roll in the same direction that you poured the line with the supplied roller. Some guys end up buying or constructing spike shoes to walk across the wet epoxy without dragging it everywhere. I didn’t need to use spikes because of the lip that goes around half of my garage so I was able to walk around without getting wet.

Epoxy-Coat recommends doing a 10x10 section, pouring another 10x10 section then going back to the first section and back rolling it again. By yourself this is a lot of hustle. I read in the forums that you can also do a section, wait 10 minutes then back roll it again before pouring the second section. This is what I did. During that 10 minute waiting period I used the cut brush to paint the lip “step” around the garage with the epoxy left in the mixing bucket. Worked like a charm. The epoxy pours and spreads more fluidly than you would expect. Keep pulling that squeegee across as far as you can to spread it out! The finished floor will be the thickest along the areas that you pour, keep that in mind.

I tried to fill a few holes with epoxy but you can’t back roll those areas or the product will get pulled right out. There was some fill here but I’ll need to go back and add more.

 

Towards the end I started to run out of base coat (A), although I had plenty of hardener (B). While mixing the last batch I came up just short of part A so poured everything into the A bucket to try to maximize the output. I figured this would result in having an excess of hardener so I would need to work fast to finish. I should have sprung for the extra half kit initially because this last batch ended up going on too thin. It did cover the entire floor but there was a clear disparity between the first few sections and the last. As you can see below, the top portion of the floor is thick and there is a distinct line between the lower half.

Not being able to settle with such imperfection, I set out to do what I should have originally and bought an additional half kit. Had I done this originally the A parts would be combined and mixed first to ensure color consistency. I would have to take my chances. To apply an additional coat of epoxy after the 24-hour window, the floor first has to be roughed up with 120-grit sandpaper. I picked up a pole sander and a pack of sanding sheets. Christine at Epoxy-Coat said that you only need to knock the shine off the floor before adding another coat. I went over the thin areas and areas that would over lap using about 3 sheets. With a damp rag I mopped up the dust and let it dry.

The rest of the process is the same for the second coat but I was much more liberal with my shark grip this round. I just poured and poured. The floor leveled up nicely and luckily the color match was almost dead on. The one thing that stands out now is the brush marks of the second coat against the area I did not re-coat. In hindsight I should have sanded the whole floor and just ran the roller over the old area to ensure a consistent profile. It still looks good. I am at peace with how it turned out because I am NOT touching this floor again!

The floor looks really slick but thanks to the SharkGrip it isn’t! Just to test I poured water on the thickest part of the floor and had my wife and kids try to slide through it. We couldn’t! Dry leaves are slippery coincidentally. Overall I am very pleased with the product and the results. I question the “3-4x stronger than concrete” claim as I was able to scrape up some epoxy overspray on the un-etched lip which came up fairly easily and was surprisingly pliable. Maybe with the clear coat it is much harder? It is no doubt miles ahead of the water-based solutions and I have no regrets except for the delayed second application.

Lessons learned

• A single roller is not enough and will start to fall apart towards the end of the application. Plan on buying at least one spare and switch it out before it starts coming apart in your wet floor.
• The supplied squeegee will not thread on the pole properly, you have to keep tightening it.
• Bugs and leaves are a pain. Bugs you can’t do much about but get all possible leaves far away from your driveway so they don’t blow in during application.
• A sharp chisel and hammer work well to open the container seals.
• Put the baking soda down after etching BEFORE washing the floor. This was not very obvious to me from the instructions the first time through.
• Epoxy is self leveling which is much more evident on thicker areas. Your brush strokes should disappear. Don’t expect holes and cracks to be filled perfectly, however.
• Squeegee, squeegee, squeegee! Keep pulling it back and back as much as you can. You really need to thin the line you poured as much as possible.
• Just like caulk, if you tape an edge to provide a nice line, pull the tape up while the product is still wet. If you wait too long you will get a raised edge.
• If you are alone, do a 10’x10’ section, wait 10 minutes, then back roll it again before moving on to the next section.
• Epoxy sets up much faster in warm weather so apply when cool if you can.
• Plan how you will roll out the floor ahead of time. Don’t paint yourself into a corner.
• Spike shoes are not an absolute necessity but will definitely make your life easier if you can get them.

CP is a fraudulent website that subscribes to and scrapes content from RSS feeds, then republishes them in their entirety. Mine and many others. Republishing other's work 100% without permission is stealing. This sad little website is built completely from stolen content. What’s worse is that they receive adsense revenue thanks to content they’ve stolen from me (and others). Look, they even have a word randomizer that changes specific words like FAST to QUICK. “Exit the Quick Lane”. Brilliant.
I encourage you to visit computersplace.net and feel free to leave an angry comment if you like. :)

**Update**

 I reported these thieves to google, since CP uses adsense, and fully expecting no action, google has gotten them to take down all posts republished from my blog. I encourage anyone else who has their feeds being republished by CP, to open a complaint with Google Adsense. It will take a very long time but they will eventually take action!

(**Updated for SEP 12, see here: LINK**)

I’m a big fan of the SEP AV product but keeping up with which build number = which version description is a pain. Unfortunately you have to do this to keep the product updated as Symantec only references the version descriptions on their download site.  The client itself only references the build number. For example, build 11.0.6100.645 = Release Update 6a + Maintenance Patch 1 (RU6 MP1). So in order to update your client from 11.0.6005.562 to 11.0.6100.645 you would need to know that you are currently running Release Update 6a (RU6a) and need to update to RU6 MP1.

Maintenance Release 4 + Maintenance Patch 2 (MR4 MP2)
Client and Manager:
11.0.4202.75
Release Update 5 (RU5)
Client and Manager
11.0.5002.333
Release Update 6 (RU6)
11.0.6000.548 (Windows)
11.0.6000.0162 (Macintosh)
Release Update 6a (RU6a)
11.0.6005.562 (Windows only)
Release Update 6a + Maintenance Patch 1 (RU6 MP1)
11.0.6100.645 (Windows)
11.0.6100.0179 (Macintosh)

Additional links:
SEP patches and upgrades
SEP security updates (“DATs”)
SEP Intelligent Updater

Disaster recovery (DR) is always a hot topic that many companies do not do at all for one reason or another or do badly. Providing DR for a virtual environment can be a particularly challenging and expensive endeavor. In my enterprise I am running ESX4 U1 on top of Brocade fiber-channel connected NetApp FAS arrays (1 production, 1 DR) with a 1Gb Metro-Ethernet link between sites. I do not currently have the luxury of using VMware’s Site Recovery Manager (SRM) in my environment so my process will be completely manual. SRM removes many of the monotonous tasks of turning up a virtual DR environment including testing your plan, but this comes with a heavy price tag. I am fortunate enough, however, to have the full suite of NetApp tools at my disposal.

Snap Manager for Virtual Infrastructure (SMVI) is NetApp’s answer to vSphere VM backups for use with their storage arrays. SMVI does require a license and requires some specific array-level licenses, such as: SnapRestore, applicable protocol license (NFS, FCP, iSCSI), SnapMirror (optional), and FlexClone. There are some specific instances in which FlexClone is not required such as for NFS VM in-place VMDK restores. All by itself SMVI can be used instead of VCB or Ranger type products to backup/restore VMs, volumes, or individual files within the guest VM OS. SnapMirror can be used in conjunction with SMVI to provide DR by sending backed up VM volumes offsite to another Filer.

Here is the backup process:

1. Once a backup is initiated, a VMware snapshot is created via vCenter for each powered-on VM in a selected volume, or for each VM that is selected for backup. You can choose either method but volume backups are recommended.
2. The VM snapshots preserve state and are used during restores. Windows application consistency can be achieved by using VMware’s VSS support for snapshots.
3. Once all VMs are snapped, SMVI initiates a snapshot of the volume on the Filer.
4. Once the volume snaps are complete, the VM snapshots are deleted in vCenter.
5. If you have a SnapMirror in place for your backed up volumes, it is then updated by SMVI.

NetApp fully supports, and recommends, running SMVI on the vCenter server for simplicity. Setup is very straight forward and only requires the vCenter server/ credentials and the storage array names or IPs/ credentials. Best practice is to set up a dedicated user in vCenter as well as on the arrays for SMVI. The required vCenter permissions for this service account are detailed in the best practices guide in the references section at the bottom of this post.

SMVI Setup

Once SMVI can communicate with vCenter, you will see the Vi datacenters, datastores and VMs on the inventory tab.

 

Backup configuration is simple. Name the job, choose the volume, specify the desired backup schedule, how long to keep the backups, and where to send alerts. If you’ll be using SnapMirror, make sure to check the “Initiate SnapMirror update” option.

By default the SMVI job alerts include a link to the job log but the listed address may be unreachable. In my case the links sent were to an IPv6 address even though IPv6 was disabled on the server. This can be changed by editing the smvi.override file in \Program Files (x86)\NetApp\SMVI\server\etc and adding the following lines:

smvi.hostname=vcenter.domain.com
smvi.address=10.10.10.10

Once you successfully run a backup job in SMVI you will be able to see the available snapshots for the volume on the source Filer. Note the SMVI snaps vs snaps used by the SnapMirror.

I my scenario, I am backing up the 2 LUNS called VMProd1_FC and VMProd2_FC which exist in volumes called ESXLUN1 and 2, respectively. Both of these volumes have corresponding SnapMirrors configured between the primary and DR Filers.

 

A couple of things to keep in mind about timing:

• It is a good idea to sync your SnapMirrors outside of SMVI which will reduce the time it takes when SMVI updates the mirrors. Just make sure to do this at a time other than when your SMVI jobs are running!
• If you are using deduplication on these volumes (you should be), schedule it to run at a time when you are not running SMVI backups or syncing SnapMirrors.

Once SMVI successfully updates the SnapMirror, you will see the replicated snapshots on the destination side of the mirror as well. DR for your ESX environment is now in effect!

Testing the DR Plan

Here comes the fun part and where having SRM would be extremely helpful to automate most of this. Thanks to NetApp’s FlexClone technology we can test our DR plan without breaking the mirrors, so you could test whenever and as often as necessary without affecting production.

First step, create a FlexClone Volume of the replicated snapshot you want to be able to mount and test with. Choose the appropriate volume then select Snapshop—>Clone from the Volumes menu. Important to note is that you must use a File space guarantee or the FlexClone creation will fail! This can be done via System Manager, CLI, or FilerView:

Your new volume will now be visible in the Filer’s volumes list, which also creates a corresponding LUN that you’ll notice is offline by default:

 

Bring the new LUN online and then you will be able to present it to your DR ESX hosts:

The LUN should instantly appear on the ESX hosts in your iGroup but if it does not run a rescan on the appropriate storage adapter:

ESX sees the LUN, now it needs to be added to the cluster. Switch to the Storage page in vCenter and select “add storage.” Select the new disk and be sure to select “Assign a new signature” to the disk or ESX will not be able to write to it! Only a new UUID is written, all existing data will be preserved.

The new LUN will now be accessible to all ESX hosts in the cluster. Note the default naming convention used after adding the LUN:

This is where things get REALLY manual and you wish you ponied that $25k for SRM. Browse the newly mounted datastore and register each VM you need to test, one by one.

 

Now your organization’s policies take over as to how far you need to go to satisfy a successful DR test. Once the VM is registered it can be powered on, but if it’s counterpart is still running in production disable its vNIC first. If you need to go further, then shut down the production VM, re-IP the DR clone and then bring it online. If you need to have users connect to the DR clone then there are other implications to consider such as DNS, DFS, ODBC pointers, etc. When your test is complete, power off all DR VM clones, dismount the datastore from within ESX, delete the FlexClone Volume on the DR Filer, bring the production VMs back up, check DNS, done. A beautiful thing and best of all the prod—>DR mirror is still in sync!

References:

SMVI 2.0 Best Practices

SMVI 2.0 Admin Guide

NetApp KB52524

While we’re on the topic of DHCP and split-scopes, it would be good to mention reservations. Reservations are used to assign a DHCP client a specific IP address, controlled via MAC address. The value of this is that you get the benefit of dynamically assigning dedicated IP addresses while maintaining manageability of global options such as designated DNS servers. It’s much easier to change the IP address of a DNS server in a single DHCP scope than it is to change on dozens or hundreds of hosts. That said, I still firmly believe in static IP assignments for critical server functions. I wouldn’t want my production SQL cluster or domain controllers running with DHCP reservations, but for ILO/IPMI, less critical hosts, etc, why not? I have had great success using reservations on management devices.

The complication occurs when you throw split-scopes into the mix. Even though a given DHCP scope is carved among several servers and the reservations will fall within one of those splits, you still need to provide redundancy for the reserved hosts. This can be accomplished by entering the reservations on each DHCP server. This works because DHCP servers can still serve reservations that fall outside of their active address pool.

You could manually enter each reservation on each DHCP server, backup/restore the DHCP database, or write your own script. Luckily the Microsoft DHCP team has already written a script for us: the DHCP Reservation Tool. It’s a simple VB script that given the right arguments can copy, sync, dump, or enter from input file all defined DHCP reservations between the servers you designate. Download the script below and rename to .vbs. I annotated it to include the command syntax. The process is called by invoking the script with the Rmanager command followed by specifying the operation and arguments. See the remarks in the script or the DHCP team post for more specifics. This worked fine in my Server 2008 R2 environment. Example:

cscript dhcp_res_mgr.vbs Rmanager –sync <source IP> <Destination IP> <all>

   

References:

DHCP Team Blog

Splitting DHCP scopes is a best practice that has been around for a very long time. The purpose is to spread a given IP scope across multiple DHCP servers in multiple locations for redundancy and load balancing. Let’s say that your company has two locations, A and B; Location A has two DHCP servers, location B has one. The IP schemes are different at each location but you want to ensure that DHCP services are available for all IP scopes at both should any of the DHCP servers ever have a problem. The best way to achieve this is to spread the scopes across all three servers. This is done by defining the scope on each server then configuring exclusions for the IP range that each server should not serve, to avoid overlap. While this was all possible in previous versions of Windows Server it had to be configured manually.

Server 2008 R2 makes this easier by adding a split-scope wizard in the DHCP MMC. First configure a DHCP scope as you normally would with the first and last IP address that you want to be dynamically assigned. Leave out the range of the IP space you intend to use for static assignments as we are only concerned with dynamic assignments. Once the scope has been defined and created it can be split by invoking the split-scope wizard in the advanced sub menu of the scope.

Once you have Selected the authorized server that you would like to add to the scope, the wizard will allow you to define the percentage of the address space that you want to give to the new server. Move the slider left and right to adjust the pool given to the new server you are configuring. If you plan to split the scope across 3 or more servers, do some quick math to determine how many addresses each should serve if you want to split the scope evenly. In the example below I am keeping 33% of the address space on the original server and giving 67% to the new server because I plan to split the scope again. The bottom portion of the window displays the exclusions that will be created on both the original host and new server.

Next you can configure a server offer delay so you can help shape which servers you want to be able to respond in which order. I intend to make my third server primary for this scope so will configure delays for both the host and added DHCP servers.

Before executing the split you are presented with a summary screen to ensure that your configuration is correct. Once you execute, the wizard will create an exclusion on the host server as well as create the new scope with exclusion on the added server. A time saver for sure!

The wizard runs through each required step and displays the result of each.

On the newly added server the scope is not automatically activated so if you made a mistake you can easily start over by deleting the new scope on the added server and the exclusion on the host server. Repeat this process on the second server to split the scope again ensuring an even split across all 3 servers. Once your configuration is solid all you need to do is activate the scope on each server you added it to.

Here is how the scope and exclusions look on each server after the split.

Original host:

2nd added server:

3rd added server:

As you can see best practice is automatically applied by defining the entire DHCP range on each server, then limiting the assignable range on each through an exclusion. Future adjustments can be made easily by changing the exclusion.

As a final step, make sure you have IP helpers configured in your switch on the proper VLAN interfaces so it knows where to send your client’s DHCPDISCOVER messages.

This one is easy to overlook and can have you scratching your head weeks to months later. Recently disk space has been mysteriously disappearing on a few select servers of mine. The free/used ratio was way out of whack with >75% of the disk being reported as used by Windows on certain drives. Auditing the drive reveals no culprit, with all visible files not consuming anything near what is being reported, including hidden files. System Volume Information reports 0 bytes and access is denied to this folder. If you use Windows Server Backup (WSB), in Server 2008 R2, and in particular VSS backups this can happen to you too (or VSS at all for that matter).

WSB uses VSS for backups and you have two choices in your backup sets: VSS full or copy backups.

 

In either case the backup job will create a Shadow Copy task on the volume pertaining to your backup. By default the shadow copy task is set to use no limit which will, eventually, completely consume your drive. The tricky part is that the space consumed by VSS is not visible in Windows Explorer and if you don’t set a hard limit on the shadow copy it can grow out of control.

Make sure to limit these and you should be ok. Changing no limit to use limit will immediately delete and free space on your server!

VSS settings are accessed by opening the properties of any drive in your server and selecting the Shadow Copies tab.

VMware View, formerly VDI, is all about desktop virtualization, at the enterprise level. View integrates with and requires vSphere and vCenter on the back-end; Set up and configuration of these components is beyond the scope of this article.  The value proposition for View is heightened security and availability for desktops by moving them into the datacenter while reducing support costs due to centralized desktop image management. View can be used to provide and control access to VMs, terminal servers, or physical PCs and supports native MS RDP as well as PCoIP for an “optimized PC experience.” View services can be accessed via View, RDP or Thin client using several different display protocols.

The desktop in the datacenter proposition is an interesting one. If using persistent VMs then you can take advantage of the recomposition feature in View and dynamically update your parent image which will trickle down to all cloned VMs. Your desktops will also enjoy HA if hosted on an ESX cluster bringing a level of redundancy otherwise not possible with traditional PC hardware. Of course you will still need to procure and deploy thin clients on user desks that will consume an image in your View environment. Another benefit of this model is that desktops will follow users so no matter where they log in they will see their assigned desktop.

My use case is a little different. I have another stubborn app that (still) requires Office 2003 which has been long gone from my desktop builds for many years now. The terminal server solution works fine for this app but then we have a resource problem as particular functions of the app like to consume 100% of available CPU, starving the other connected users. For this particular case View is a great solution because I can deploy a desktop to each application user and guarantee a predictable performance level for each VM, eliminating contention. Through the View Connection Server I can broker client requests and direct my users to a single pool that will present their work spaces to them dynamically. In this project I will be integrating View into my production ESX cluster to provide 10 dynamic desktops to users of a business application.

View can be licensed in two flavors, Enterprise or Premier, VMware’s new scheme, and for new or existing vSphere customers. The key difference between the two is Premier comes with View Composer, Offline Desktop (experimental), and ThinApp. View Composer is required if you want to use the linked clone feature. Linked clones are spawned from a parent but are a fraction of the size (10MB) and point back to the parent. List prices range between $50 and $250/ concurrent desktop. Read more about the version differences here: VMware View.

Architecture

The required components of this solution are:

• ESX
• vCenter running View Composer
• View Connection Server (VM)
• Active Directory

The View Connection Server (VCS) will host the broker service that will direct clients to their presented desktops. VMware plainly states that this server role should not be installed on your vCenter server and must run on Server 2003 (R2) only, Server 2008 is completely unsupported at this point. VCS is fully supported as a VM in the cluster so no worries there. VCS can scale to support additional replica servers for large environments and security servers for DMZ deployments . A single VCS instance can support 2000 simultaneous connections (direct, RDP). VMware documentation can help you calculate overhead for varying workloads running on various desktop operating systems.

Here is my architecture as it will be implemented (terminal servers and PC are evolutionary considerations):

View Composer

While spinning up my VCS VM, I installed View Composer on my vCenter server. Although technically not supported, I was able to successfully install Composer on Server 2008 R2 with SQL Server 2008. First create a new SQL database for Composer where your vCenter database lives, View will use Windows authentication mode.  The key to getting through the installation is to set up the ODBC via the applet in the administrative tools folder (%windir%\system32\odbcad32.exe), not via the Composer setup wizard which will open C:\Windows\SysWOW64\odbcad32.exe.  Setup will only find a DSN configured with the administrative tools applet. If you use the applet called by the setup wizard you will get this error:

 

The rest of setup is straight forward and will result in the VMware View Composer service being installed and started. That’s it. There is nothing else to configure for Composer.

View Connection Server

Once the 2003 R2 VM is ready install VCS. VCS can be installed in one of 3 roles, for my purposes Standard is fine. Setup will also install an instance of MS ADAM to store View configuration data. After the first server is setup, if you need you can install replicas. The VCS will also run an instance of TomCat to host the View Manager website.

 

Parent VM

Before we configure View Manager, let’s get the parent VM ready. In vCenter create a regular VM with the desktop OS of your choosing, I’ll be using XP Pro SP3. Install all patches, needed software, antivirus, ODBC settings, and join it to the domain. Don’t forget to install the View agent as well and disconnect any floppies or CD-ROMs! Once everything is configured correctly take a snapshot in vCenter as this is what will allow the VM to be a parent in the View environment. This snapshot provides the baseline for the parent image.

View Manager

View Manager is the administrative tool used to configure View settings, accessed via a web browser. The site is accessed by connecting to your VCS server: https://VCS/admin. This is where you input your licensing information for your View environment which should be done first. Click Configuration, then Edit License under the Product Licensing and Usage heading. Next associate your vCenter server. You will need a domain service account that has administrative rights on both vCenter and VCS servers, as well as the ability to create and delete computer objects in the OU of your choosing in AD. This service account will be used to dynamically create VMs, join them to the domain, and then delete both when not in use. It does not need domain admin rights if properly delegated.

Add any users or groups that you would like to allow administrative access to View Manager. At this point we should now be ready to set up a desktop pool and start testing View. Click Desktops and Pools, then Add… to start the setup dialog.

There are 4 different pool types you can set up depending on your requirements, I’ll be setting up an automated desktop pool.

 

Desktop persistence will determine a few different features available to you after the pool is created. Persistent is suited for permanent user desktops and can be used with the parent VM recomposition feature while non-persistent will be temporary and cannot be used with recomposition. My View desktops will be used dynamically to run a specific application, not as permanent desktops so I will use non-persistent.

Along with non-persistent desktops I want to use the linked clone technology which will create clones of my parent VM that are a fraction of the size of the parent, 10MB per VM. This is very cool technology and huge disk space saver.

 

Configure a unique ID/ display name then move on to desktop/pool settings. Configure the desired behavior for each setting. I want to force the RDP protocol and destroy the linked clones when a user logs out.

Provisioning settings will determine the automated behavior of your desktop pool. I am licensed for 10 desktops but would only like 1 available at all times since they will not be used daily. As soon as a user logs into one another will start spinning up automatically .

Next select the parent VM you created and snapped earlier. Remember that only VMs with snapshots will be displayed here.

Once the parent VM has been selected you will see the snapshots attached to it. Select the appropriate snap and click next.

Setup will next create a folder in the location of your choosing to house the View VMs. It will name the folder based on the Unique ID you created earlier. Choose your host or cluster then select a resource pool and datastore. I’m not currently running DRS so I can’t create a resource pool in my cluster and am stuck using the default pool. Next move on to QuickPrep. This is where the integration magic is set up. If you set up your service account as I described earlier you will see it here in the dropdown. In the AD container box, enter the AD DN of where these VMs will live in your directory (in reverse order). Make sure to leave off the domain designations or setup will fail! (DC=domain,DC=com).

Review the settings on the next screen then click Finish to commit. You can now safely turn off your parent VM. Next you need to grant access to the users you want to be able to use the View desktops, this is done via the Entitlements… link.

Depending on your provisioning settings, you should now see at least the first desktop being created in vCenter. First View will create a replica source of your parent VM. This copy process will take a few minutes. Browse your datastore to see the new replica folder and files.

Once the replica is in place, linked clones will spin up much faster since they will point back to the replica source. Linked clones will continue to increase in size over time so it is a good idea to refresh them occasionally to reset their space consumption. When first created the linked clones are extremely small.

 

The View client should now be installed and users can log into the environment.

Although recomposition-on-the-fly is not available for non-persistent VMs you can still refresh your parent VMs, albeit a much more manual process which requires down time.

1. Destroy all desktop sources in the pool via View Manager
2. Disable the pool and new VM provisioning
3. Delete the snapshot on the desktop pool’s parent VM in vCenter
4. Make your changes and shut down the VM
5. Take a new snapshot
6. Edit the desktop pool in View Manager to point at the new snapshot
7. Re-enable the desktop pool and VM provisioning

Please note that by deleting the last clone in the pool will also trigger a delete of the replica. So when you enable the pool again the replica will have to be created again.

As of this writing only build 4.0.1-233023 is publicly available on VMware’s website. I was having a problem with provisioning where after a VM was spun up, View Manager would flag an error status and spin up another, even though the original was fine and fully usable. “View Composer agent initialization state error (6).

VMware’s posted solution to this problem is to create a batch script that reboots the VM again after the provisioning process has completed. This did not resolve the issue for me so I opened a case with VMware. They directed me to the bits for build 269620 which has resolved the issue! The download link I was given is public so I’m going to assume it’s ok to post here, see the references section at the bottom.

Client deployment can be easily accomplished using KBox, SCCM, or other deployment solution. Here is the command string I used to deploy in my environment (change the server name):

VMware-viewclient-4.0.1-269620.exe /s/v/qn DESKTOP_SHORTCUT=0 VDM_SERVER=<ServerName> REBOOT=Reallysupress

Conclusion

I am extremely impressed with VMware View and the lengths VMware has gone to, to ensure seamless integration into an existing enterprise environment. AD-integration is seamless as is desktop provisioning. I should not have to touch my View environment unless the parent VM needs to be updated. It is, however, additional infrastructure in what seems to be an endlessly expanding datacenter service footprint but the value and rewards are solid. If you already own or are planning to purchase vSphere and need a virtual desktop solution I strongly recommend you consider View 4.

 

References:

VMware View 4.0.1-269620

View 4 Architecture Guide

View 4 Deployment Guide

View 4 Admin Guide