Installing first KMS Server

These are the steps I followed to install the KMS server. We determined that due to the number of client activations, and the capacity of our infrastructure we had no problems installing this server on our secondary domain controller. From here on we will call it DC2.

1. Log onto https://www.microsoft.com/licensing/servicecenter/ and fetch your key: “Win Srv 2008 R2 Data Ctr/Itan KMS C” – Note your key may be similar, but either way it must end in either KMS B, or KMS C.
2. On DC2 we run CMD with elevation
3. Type slmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx where the last section is the Key from your volume licensing website.
   
4. Open “Windows Firewall with Advanced Security” via Start menu -> Administrative Tools.
5. Under Inbound Rules scroll down to “Key Management Service (TCP-In)”, right click and select enable.
6. Reboot the machine – note you can restart the Software Licensing service but I preferred to reboot it (seeing as the server was not in use for anything else)

   net stop sppsvc && net start sppsvc

7. Active server after reboot. This can be done via the GUI or by executing the following command from an elevated command prompt:

   slmgr.vbs /ato

8. Enables automatic DNS publishing by the KMS host by entering the below command in an elevated command promt. Note this should already be enabled, but just in case, we execute the command.

   slmgr /sdns

Now you are done installing your KMS server.Note this will provide activation for clients and/or servers depending on the KMS key you used to activate DC2. Office KMS activation will be covered in a later section.

I do recommend verifying that the SRV record in DNS is created. Note that you should have no problems with the automatic creation if you are using the vanilla install of AD and have no specific security restrictions in DNS. To verify that the DNS record has been created open up DNS and check. Refer to the screenshot below to see where it lives:

Installing Office KMS Host

As mentioned above we have determined that the one KMS box (DC2) is suitable to do all of our activations for Microsoft products, so now we have to configure the Office KMS host on DC2. To do this we do the following:

1. Log onto https://www.microsoft.com/licensing/servicecenter/ and fetch your key: “Office 2010 Suites and Apps KMS” – Note your key may be similar. If unsure speak to your Microsoft Account Manager.
   
2. Download the Office 2010 KMS Host License Pack from the Microsoft website: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=97b7b710-6831-4ce5-9ff5-fdc21fe8d965. Its only 903kb so wont take too long.
   
3. Execute KeyManagementServiceHost.exe from your existing KMS server> In our case its DC2. Follow the prompt to finish the setup process.
   
4. When prompted enter the KMS key for Office 2010.
   

Thats it. Just as easy to setup. Now you are ready to activeate Office 2010 with KMS. to help monitor this, please refer the the section below.

Administering the KMS server

I take it now you want to see whether it works and if clients can be activated. Now i will go into administering the KMS server, which will be quite brief as there is not much to it, and is really only there to aid in troubleshooting, and to have a sticky beak when implementing it. Once its running there is no real reason to keep going in and checking up on it.

All functions to view settings and make changes are done through the already used VBS script slmgr.vbs. To see all the commands simply run slmgr from the command prompt. Note to execute changes you will need elevated command prompt. You will see the following screens:

So the most common command that i used was:

Displays license information (KMS Activation Count)

Displays detailed license information

For Office specific information you can run the below command to get the info wanted:

Note I add cscript to the front of the command so that the output stays within the command window, this lets me output/scroll if there is a lot of data where as the usual vbs dialog crops the output.

Configuring KMS Clients

By default, Volume Licensing edition of Windows Vista, Windows 7 , Windows Server 2008, and Windows Server 2008 R2 are KMS clients. If the computers the organisation wants to activate using KMS are using any of these operating systems and the network allows DNS auto-discovery, no further configuration is needed.

If required you can configure the KMS client to connect to a specific KMS host, use a specific port and disable KMS auto-discovery.

When deploying KMS clients using WAIK you can use 2 different methods to prepare the client:

• SYSPREP – run Sysprep /generalize which will reset the activation timer along with removing SID and a few other settings. Read about this before actually using it.
  
• Software License Manager – run slmgr.vbs /rearm in an elevated command prompt to reset the grace period back to 30 days. Note you can only perform this 3 times in total.
  

You can also manually force activation of the client by using the GUI from Control Panel -> System or by running slmgr /ato.

If you want to convert MAK installations of Windows or Office to KMS, you need to change their product key, and then reactivate. Use the below keys to perform this:

You can convert Windows and Office from MAC to KMS using the GUI available, or you can use the following commands:

Windows
To install a KMS key, type slmgr.vbs /ipk KmsKey at a command prompt.
To active online, type slmgr.vbs /ato at a command prompt.
To activate by using the telephone, type slui.exe 4 at a command prompt.

Office
To install a KMS key, type ospp.vbs /inpkey:KmsKey at a command prompt.
To active online, type ospp.vbs /act at a command prompt.

Important Links

Here are the resources that I got most of the information I needed.

• Deploying KMS Activation
  http://technet.microsoft.com/en-us/library/ff793409.aspx
  
• How to install or Update KMS on Server 2008 for windows 7 and Server 2008 Support
  http://myitforum.com/cs2/blogs/jmarcum/archive/2009/10/29/142586.aspx
  
• Plan volume activation of Office 2010
  http://technet.microsoft.com/en-us/library/ee624358.aspx
  
• Deploy volume activation of Office 2011
  http://technet.microsoft.com/en-us/library/ee624357.aspx
  
• Troubleshoot volume activation for Office 2010
  http://technet.microsoft.com/en-us/library/ee624355.aspx
  
• Tools to configure client computers in Office 2010
  http://technet.microsoft.com/en-us/library/ee624350.aspx

• Slmgr.vbs Options
  

  http://technet.microsoft.com/en-us/library/ff793433.aspx
  

1. Download the ESXi 5 .ISO and have it ready on your PC
2. Download UNetbootin and run the software (Windows – Mac OS X – Linux).
3. Start the UNetbootin application and choose Diskimage (ISO) and browse to the downloaded ESXi 5 .ISO file.

1. Choose Type: USB Drive and choose the correct USB drive letter that you want the bootable installer to be installed to.
2. There you are one bootable USB image for ESXi 5! Enjoy!!

1. Download the XenServer 6 .ISO and have it ready on your PC
2. Download PendriveLinux (http://www.pendrivelinux.com/) from here (http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/)
3. Launch the Universal USB Installer
4. From the drop-down, scroll to the bottom and choose “Try Unlisted Linux ISO (NEW Syslinux)”
5. Choose the location of the XenServer ISO
6. Select the drive letter for your USB
   1. (optional) I chose to format the drive
7. Click Create
8. After creation is finished, on the USB drive, navigate to the /boot/isolinux folder on the root of the USB
   1. Rename the ‘isolinux.cfg’ file to ‘syslinux.cfg’
   2. Rename the ‘isolinux.bin’ file to ‘syslinux.bin’

There you are one bootable USB image for XenServer 6! Enjoy!!

vCenter Server Virtual Appliance provides all features as the Windows vCenter Server but does not support the following features:

• Microsoft SQL as the database for vCenter – requires stable ODBC driver for Linux that can scale.
  
• vCenter Server Linked Mode – requires ADAM.
  
• vCenter Server Heartbeat – requires Windows.
  
• IPv6.
  
• Single sign-on using Windows session credentials.
  
• VMware View Composer (Linked Clones) – installed on Windows vCenter Server only.
  
• vSphere Storage Appliance – VSA Manager & VSA Cluster Server installed on Windows vCenter Server.
  
• VIX Plugin for vCenter Orchestrator – VMware Tools API only works with Windows vCenter Server.
  

Other VMware products that work with the vCSA:

• vCenter Operations.
  
• vCenter Orchestrator.
  
• vCenter CapacityIQ.
  
• SRM5.
  
• Auto Deploy.
  
• vCenter Update Manager.
  
• vMA.
  
• vSphere Client.
  
• vSphere Web Client.
  

The following table lists the required files that you will need, gather these files before proceeding.

Watch the 10-minute installation video (Optimized for iPad)

http://www.youtube.com/watch?v=e6DY7FHEr2M&feature=player_embedded

Deploy the vCenter Server Linux Virtual Appliance

• Launch your vSphere Client and navigate to File | Deploy OVF Template.
  
• Browse to the location of the vCenter Appliance .ovf file, then click on Open.
  
• On the following screen click on Next.
  
• Then click on Next again on the OVF Template Details page.
  
• Under Name and Location, give your vCenter Appliance a name then click Next.
  
• Choose a datastore then click Next.
  
• Select a disk format on the next page then click on Next to continue.
  
• Click on Finish to start deploying.
  

  
  

Configuring the vCenter Server Linux Virtual Appliance

• Boot the appliance.
  
• Open a vSphere Client console session to the virtual appliance and configure the network and timezone.
  
• Now open up a browser and type https://<ip_of_appliance>:5480 to continue the configuration.
  
• Accept the certificate error to continue.
  
• Login as root, the default password is vmware.
  

• Now read through the entire EULA and click on Accept EULA to continue. Please be patient while the vCenter is configured (this takes a few minutes). If you look at the appliance remote console you’ll see the services being configured and started.
  

• You can start using the web interface again once the console screen returns to default.
  

• Next click on Status, and view the current status of the vCenter Server. The service should be on a Stopped state and the Database Type should show not configured.
  
• Click on the tab, you will notice that there are no DNS Servers configured and the appliance’s hostname is the standard localhost.localdom, lets change this.
  
• The best way to change the Network settings is to go to the console of the vCenter server and select configure network. Walk through changing the IP address, DNS servers, and the Hostname for the appliance.
  

  
  

• Log back into the interface using the IP address which you just configured. https://<ip_of_appliance>:5480 Setup authentication by clicking on and then on either NIS or Active Directory. My ‘thevbox.info’ lab environment uses AD.
  
• Click on the tick box and then fill in your domain details and then click on Save Settings. You should receive an Operation is successful message to confirm that the authentication settings has worked.
  

  
  

• We now need to configure a database for vCenter to use, for this article, let’s use the embedded DB2 database. Click on to continue.
  
• When using the embedded database, there is no need to enter any details, just click on . This will take several minutes to complete, once done click on . After what seems to be too long, the database will complete configuration, you should receive an Operation is successful message to confirm.
  

  
  

• Set the time zone by clicking on and then . Select your time zone and then click
  

  
  

• Now reboot the virtual appliance one last time. To reboot click on and then click on . Click Reboot again to confirm.
  
• This time the vCenter Appliance will successfully start the vpxd daemon and initialize the database, eventually vCenter 5.0 will be ready for you to use.
  

Connecting to vCenter 5.0 for the first time

With all VMware vSphere Clients, when you start the vSphere Client and connect to either a vCenter Server or an ESX/ESXi host, it will check whether the vSphere Client is compatible. This is still the case with vSphere 5.0 and you will need to update your vSphere Client if you haven’t already done so. You can update by connecting to vCenter Server or ESX/ESXi or you can download the vSphere Client executable from the VMware Downloads website.

1. Launch the vSphere Client and connect to your newly configured vCenter Server.
   
2. You must use root | vmware to login, domain credentials will not work until the permissions are added to vCenter.
   

1. Update the vSphere Client as necessary.
   
2. Add an AD group into vCenter permissions and set the role as Administrator. [See video].
   
3. Now you will be able to log in with domain credentials.
   
4. You will need to enter your username in DOMAIN\Username or username@DOMAIN format.
   

The little things…

• To make sure that you can continue to use host customization files, use the following KB Article combined with WinSCP. Connect to the virtual appliance using WinSCP and navigate to the /etc/vmware-vpx/sysprep and place the appropriate sysprep files in their proper folders.

  

• More to come….

This should be a welcome upgrade for those who use provisioning server and use the built-in distributed switches or the Nexus 1000v. I will definitely be posting more on this version of Provisioning Server at a later date. Right now I am going to get this deployed in my lab! ENJOY!!!

• Introducing XenApp 6.5, The definitive solution for on-demand app delivery: http://bit.ly/r2xkFf

• HDX is even better in XenDesktop 5.5:  http://bit.ly/rj8Hrw

• Personalization – Where does Citrix RingCube fit?:  http://bit.ly/o0nD8C

• New Receivers for Windows and Mac (OS X Lion) raise the bar along with Citrix XenDesktop 5.5!:  http://bit.ly/oSMJ8l

• Citrix XenClient 2 released, Find out what’s new:  http://bit.ly/qeuGhO

• Citrix XenDesktop 5.5 Enhances User Personalization & High-Definition Experience over the LAN or WAN:  http://bit.ly/rde32F

• XenDesktop 5.5 – Optimizing for the Private Cloud:  http://bit.ly/ojppNT

Four major concerns for security practitioners, and how to prepare yourself and your company for the cloud.

This is the second part of an ongoing series concerning the management of risk in the cloud. You can find my first segment here.

1. Data Separation Concerns. – Data used to be stored along with each server before SAN and NAS became popular, even when they became popular and were widely adopted they were stored internally to the organization and therefore were physically separated from other organizations data. The physical separation of data is a common practice even when a company uses hosting services. When a hosting service organization provides a shared facility to multiple customers, then there is a sharing of some network resources (usually separated by VLANs), and rented or leased servers provide a separation of equipment on which to run their own applications and storage of data. This is also true of Application Service Providers (ASPs). With the introduction of public cloud computing these lines have been blurred and typically all computing resources are then shared, thus the rise of concern.
   
2. Increased Network Exposure. – Network exposure has been a concern for security practitioners since the 1970′s. With the introduction of the cloud, the level and possibility of exposure is greater than it has ever been. Direct navigation via the Internet to access company resources has presented a greater increase of risk to threats that usually could be controlled by the perimeter of company firewalls and security practices. In a typical scenario a company’s resources are compartmentalized and they have an Internet connection to the outside world to traverse the outside world. If an attack causes interruptions to Internet traffic, vital end of quarter or end of month processing can still occur. However, when the resources are not internal to the organization anymore and a DDOS or BGP attack happens there is a separation of those resources causing an organization an indefinite period of interruption.
   
3. Increased Application Exposure. – This is mostly about location, location, location. Applications that have typically been located internally are now external and are exposed in the public cloud via the Internet. Software as a Service (SaaS) providers disagree and state that their applications are safe because of a limited attack surface possibility. The use of SaaS requires only an Internet browser that is used for accessing these applications from the client side. This tremendously cuts down on the ports used to traverse the server-client relationship thereby creating less exposure for attacks to occur. SaaS providers have taken precautions for securing their applications and their respective APIs. “The fact that many SaaS applications are actually built by third parties on other cloud services (either PaaS or IaaS) further calls into question the security of SaaS applications. Additionally, many SaaS APIs (including Amazon Web Services, Google, and Salesforce.com) use REST (REpresentational State Transfer), which has no predefined security methods.”
   
4. No Established Governance Model. – How are security professionals supposed to protect an environment for which there are no predefined boundaries or rule sets? Cloud computing by its definition should be considered an untrusted environment, however a governance model is currently being developed for the emergence of cloud computing and should be available soon.
   

HOW TO PREPARE YOUR COMPANY FOR THE CLOUD

Does your company deal with sensitive, regulated or classified information? If so, then moving to the public cloud may not be for you. Non-sensitive, non-regulated, and unclassified data which is intended to be public or already is public is a good candidate for public cloud use. Community clouds can still be an attractive option for sharing data between companies.

Security practitioners should take the appropriate steps when investigating the use of public cloud services for their companies:

• Perform a self-assessment:
  
• Anonymization of data:
  
• Perform due diligence:
  
• Emphasize endpoint security: 

After going through introductions we talked a bit about why Trend Micro purchased Mobile Armor recently and now the U.S. Government is their largest customer. We talked a bit about Drive Armor, Data Armor products and some of their other new security products. Trend Micro is set apart from everyone else from the standpoint of how they integrate with VMware. Securing your journey through the cloud is important to Trend Micro. Making sure that your private and public cloud is secured and not bogged down by the overhead of typical anti-virus products of the past. By using the API written by VMware you can leverage the vShield EndPoint product and now use agent-less AV within your cloud infrastructure. You can use the Deep Security product on SQL (2008, 2005), Oracle (10g, 11g), and Apache Derby databases. Deep Security is database intensive and needs to be designed with this in mind. Offloading the database to an enterprise database server would be essential to the success of a project in large environments as there is a lot of activity in the database. Pruning the database after a specified number of days would be a prudent thing to consider talking about with DBAs as the database growth can get out of hand. Specific settings within the DSM can help minimize the growth rate and also help purge records after specified timeframes.

In a VDI environment you really have to watch out for AV storms. An AV storm is what we would see if every time that there is an update or environment scan the CPU and memory resources are consumed for every desktop in every pool and your VDI environment can come to a screeching halt; extreme lag. In traditional agent based AV, if your parent image is not updated every time the AV engines and database is updated (which is normal) then every time a linked clone reboots it also has to do AV updates all over again. Using agentless AV you can avoid resource overhead by leveraging vShield and the Deep Security Virtual Appliances (DSVA) located on each host. When performing VDI assessments we have found that the number one application resource hog is the antivirus software in 99.9% of our clients. In the Deep Security product the DSVA holds the updated AV signatures and engines and performs the scans in an agentless deployment, thus enabling higher VM densities in VMware environments.

Currently in the Deep Security 7.5 product, the solution is comprised of 5 modules:

• Anti-Malware
• Deep Packet Inspection (DPI) – [comprised of]
  • IDS/IPS – Virtual Patching
  • Web Application Protection
  • Application Control
  • Stateful Firewall
• Log Inspection
• Integrity Monitoring
• Firewall

Out of the 5 modules, the Anti-Malware, DPI, and Firewall modules are agentless (leveraging the DSVA). The other two modules require a Deep Security Agent (DSA) to be installed onto the client. There are plans to move the other two modules to agentless as well when the API is updated in future revisions of vSphere. The product covers physical, virtual, and cloud environments. If the agent needs to be loaded the agent will control everything but the Anti-Malware portion which will still take advantage of the vShield EndPoint API and use the DSVA instead. This allows for updates of engines and signatures to still be completed by the DSVA as well as scans. The other 4 modules will be managed and controlled by the DSM but will reside on the client. Javascript will be needed for management of the DSM. The following table identifies which protection is provided by the Deep Security Virtual Appliance, the Deep Security Agent, or both:

** A note about the DSM: Make sure that you install the DSA on the DSM so that it can protect itself, afterwards assigning the ‘Deep Security Manager’ security profile to the server. So from a plan and design perspective, this DSM server should fall under the same cluster being protected by the DSVAs.

The core architecture is made up of the following:

• Deep Security Manager (DSM)
• Database – [Named or TCP Pipes]
• Deep Security Agent (DSA) – [using port 4120 & 4118 to/from DSM]
• DSM Management Console – [using port 4119; HTTPS back to DSM]
• Trend Micro Security Center – [using port 443 (SOAP over SSL) back to the DSM]
• Deep Security Virtual Appliance (DSVA)

For redundancy, the DSM can be split into a Primary and Secondary nodes sharing the same records on the same database. DSAs can switch between nodes if this connection with a specific DSM fails or times out. Using the dsa_config.exe executable you currently can configure the DSA on a case by case basis. This will probably disappear in future releases as it is not needed. All agents are configured and managed from the DSM console.

In VDI environments you need to tell DSM to ‘Allow Agent Initiated Activation’, in addition to this you should setup an event based task to look for these new VMs and to register them in the DSM. The event based task can be specified to assign a security profile based on Computer Name, vCenter Name, ESX Name, Folder Name or Platform. Using this event based task, you can assign the appropriate profile and activate the VM without a massive hands on approach to register each and every linked clone that appears. Who wants to do that anyway?

You also have a checkbox here in this System Settings window that states if the Computer name already exists to do the following:

1. Don’t allow activation
2. Activate a new computer with the same name.
3. Reactivate the existing machine

I ran across a report showing comparisons between the Trend Micro Deep Security product and both McAfee and Symantec. The article stated that “Tests showed that Trend Micro Deep Security, which provides an agentless virtual appliance-based approach to anti-virus protection optimized for virtualization, consistently consumed less CPU, RAM and disk I/O resources than the non VM-aware implementations where anti-virus agents and processing resided in each and every Windows 7 virtual machine.”

Also, from personal experience there is a very particular way to prepare your ESX hosts for use with Deep Security. If you do any of these steps out of sequence then you will end up blowing up the installation and will need to back everything out and start over on that host for it to work properly. Sometimes an automatic back out doesn’t even work and you have to uninstall Deep Security manually from the host. These steps have been documented as part of the Varrow best practices for our engineers to follow. BTW… don’t use SP1 and always use SP2 or better when installing Deep Security!! When using SP1 version, when you prepared the hosts, it would reboot them without warning. L I believe that this had to be a reason behind releasing SP2 so early after SP1 was initially released.

All-in-all this was a good class in which I was able to ask many questions that were based on issues and challenges that the Varrow Desktop Virtualization Team has run into with the product at our customer sites. The challenges ended up either being successfully resolved through actions identified in the user and installation guides, or were minor annoyances that we could present to TM for future release considerations. These solutions weren’t intuitive or easily found either (identified after some digging), but the Trend Micro engineers were very knowledgeable and helped us find the answers.

Shavlik is one of the best patch management software on the market. I personally think that this could only get better since being snatched up by VMware. I will definitely be downloading this soon to get caught back up on the technology. We should be seeing more emphasis placed on this soon.

To support XenApp 6.0 on Windows Server 2008 R2 with SP1, just install CTX125388 – Hotfix XA600W2K8R2X64001. In http://support.citrix.com/article/CTX126711, Microsoft Windows Server 2008 R2 Service Pack 1 – Known Issues, there are no further issues reported.