The client software for Microsoft Lync 2010 is only available as an EXE file. But when you wish to distribute the Lync client to multiple workstations, it is much easier to use the software deployment method using Active Directory and Group Policies. For this purpose the presence of an MSI file is required. In this article I will describe the required steps for a successful distribution using Group Policies.
Extracting the MSI file
The first step is to obtain the MSI file from the EXE file. First we need to run the EXE file and fully install the Lync client software. After the installation has finished, use Windows Explorer to open the C:\Program Files\OCSetup folder and you will find a Lync.msi file in here. Copy this file into another folder.
After the file has been copied, you can safely uninstall the Lync client software again.
Attempting to install the MSI file
In general it is good practice to first try to install the MSI file manually. If it even doesn’t install manually, how on earth will it ever get installed using a GPO? So, let’s give it a try…
Unfortunately the installation fails with an error message saying that the installation can only be run using the setup program.
Microsoft intentionally disabled the ability to install the MSI file since the setup program not only installs the Lync client itself, but also checks for other required components. Among these are the Visual C++ runtime components and the Silverlight browser plugin.
So if we first ensure that the required components are preinstalled, there should be no reason why we can’t use the MSI file to install the Lync client.
Installing the MSI file using the documented method
Although the recommended installation method is by using the setup program, Microsoft does provide a documented method to install the MSI file anyway.
According to KB article 2477965 in the Microsoft knowledge base it takes a registry modification to allow the MSI file to install. Open the registry editor on the computer and browse to the following registry key:
Now add a new DWORD value named UseMSIForLyncInstallation and set this value to 0x00000001. After setting this value it will be possible to install the Lync client using the MSI file.
This setting is however not included in the ADM template, so you must either write your own ADM template for this or use some other method (scripting?) for configuring this registry key on all computers.
Installing the MSI file using the alternative method
Fortunately there is an alternative method for allowing the MSI file to install without the need for configuring the aforementioned registry key on all computers. Remember that the MSI file checks if it is being invoked by the setup program? And that it also checks for the presence of a registry key? So why not just remove these checks from the MSI file?
Start your favorite MSI editor and open the Lync.msi file. As an example I used ORCA to edit the MSI file. You can download ORCA here.
First create a new transform by using the Transform|New Transform menu. After the new transform has been created browse to the LaunchCondition table in the left pane and in here you have to look for the line that reads:
OCSETUP OR Installed OR USEMSIFORLYNCINSTALLATION = "#1"
This is the check that prevents installing the MSI file. Now simply delete this line. Generate the transform by using the Transform|Generate Transform menu and save it to the same location where the MSI file is in.
After making these modifications you should be able to create a new software distribution by adding the MSI file and the generated MST file to a GPO and distributing this to all computers will now be a piece of cake.
Nowadays there are several different virtualization products available on the market. All these products offer the same basic functionality and can be divided into two major categories: software based virtualization and hardware based virtualization.
The first category requires an Operating System like Windows or Linux to be installed on the machine first. The second category doesn’t require an Operating System to be installed, but in fact provides it’s own OS or a hypervisor. Since this hypervisor runs straight on top of the hardware it is often referred to as a bare metal virtualization solution.
As far as performance is concerned, a bare metal solution will without a doubt offer better performance than a software based virtualization solution. But how do these bare metal solution compare to each other? And is there a noticeable performance drop when using a virtualized workstation compared to a “normal” installation?
Just to satisfy my own curiosity, I decided to put this to the test.
Tested products and test environment
There are numerous bare metal virtualization products available on the market, but I limited the tests to several products I have experience with myself. The products I included in the tests are:
- Microsoft Windows Hyper-V 2008 R2
- VMWare ESXi 4.1
- Citrix Xen Server 5.6
- Citrix Xen Client 1.0
All tests were performed on the same workstation. For this purpose I have used a HP Compaq 6000 Pro SFF. The hardware specifications of this machine are:
- Intel Core2 Duo CPU E8400 @ 3,00 GHz
- 2048 Megabyte RAM
- Intel Q45 / Q43 graphics chipset
- Western Digital WD3200AAJS-60Z0A0 Hard Disk
For the tests I created a new Virtual Machine with a single CPU / core with 1024 MB of memory and a 64 GB hard disk. In the Virtual Machine I installed Windows 7 Professional (32-bit). After installing the Operating System I also installed the appropriate tools (Xen tools, Integration Services, VMWare tools, etc.) and installed all available updates for Windows 7 that were available through Windows Update.
For comparison I also installed Windows 7 straight onto the workstation. During the tests I limited the number of available CPUs to 1 and the amount of memory to 1024 MB.
To test the performance I used Passmark Performance Test and ran the standard test suite. Because none of the virtualization products supported 3D acceleration I excluded the 3D graphics test from the results. I also excluded the CD performance test, because these will not be very important in everyday situations.
For the final test result I repeated the standard test suite 5 times, dropped the highest and the lowest result and computed the average of the remaining results. These final results were compared to the result of the performance test of a normal Windows 7 installation. The latter received a score of 100%, the others were computed as a score relative to this.
For the overall score Passmark Performance Test calculates a score for each category:
- 2D graphics
As one would expect the performance of the Virtual Machines is slightly worse than the performance of the physical machine. The difference between the Virtual Machines is almost negligible. The only exception is the 2D graphics score where VMWare ESXi score considerably worse compared to the other virtual machines.
Surprisingly, the disk score of most virtual machines is higher than the score of the physical machine. Also here VMWare scores considerably worse.
The overall CPU score shows there is not much difference between the virtual machines, neither is there a large performance drop. The only considerable difference compared to the physical machine is during the Find Prime Numbers test.
2D graphics score
After installing Windows 7 in the virtual machines, only the Hyper-V virtual machine had a suitable driver for the display adapter installed. The others were using the standard VGA display driver. During the tests the physical machine performed exceptionally poor, compared to the virtual machines. This poor performance was caused by the Intel graphics driver that was installed. After installing the standard VGA driver, the performance was normal. Since most virtual machines were using the standard VGA driver anyway, using this driver also on the physical machine would provide better results for comparing the graphics performance.
In several tests (Image Filter, Windows Interface, Complex Vectors) Microsoft Hyper-V clearly outperforms its competitors. But in the Image Rendering test it performs the worst. The overall score of Hyper-V is almost equal to Xen Server, with Xen Client following an a short distance. VMWare ESXi is trailing in almost every 2D graphics test which results in the lowest overall 2D graphics performance.
The memory test do not show much different between the physical machine and the virtual machines. Only on the Large RAM test the physical machine performs much better. Of the virtual machines Hyper-V performs much better than its rivals during this test. Because of this, Hyper-V achieves a slightly better overall memory score compared to the other virtualization products.
During the disk tests almost all products, except VMWare ESXi, perform better than the physical machine. Especially the test scores of Xen Client are consistently high. Hyper-V does exceptionally well on the sequential write test, but scores considerably lower during the random seek + read/write test.
Because of the high score during the sequential write test, Hyper-V achieves the highest overall score, closely followed by Citrix Xen client.
So why are most virtual machines performing better during the disk tests than the physical machine? The only reason I can think of is caching. During the standard disk tests, Passmark Performance Test uses Windows API calls to read from and write to the disk. Because of the use of caching, the read/write operation seems to be finished as far as the OS is concerned, while the data has not been written physically. Because the data is still in the cache, the read operation will also finish much quicker.
This also seems to be supported by the fact that especially Hyper-V showed strange results during the tests. The tests are most likely designed in such a way that the sequential write test writes some data and the same data is read again during the read test. Because the data written is still in cache, the read operation can also retrieve the data from the cache. This resulted in scores that were about 100 times higher the the score of the physical machine. I have neglected these scores during the tests and included only “normal” test results.
Besides the standard disk tests, Passmark Performance Test also provides advanced tests. These tests provide a simulation of read/write patterns for workstations, file servers, database servers and web servers. It is also possible to use different methods of accessing the disk, besides the Windows API calls. Perhaps these advanced tests will show different results. Maybe I will do a similar comparison focusing on the advanced disk tests in the future, if time permits it.
My basic goal for this comparison was to compare the performance of different virtualization products compared to a physical machine. For all products I have used the out-of-the-box configuration settings.Most likely it is possible to tweak the configuration to achieve a better score.
It was also not my intention to compare all features of the different virtualization products and pass judgment on which of these products is the better one. I think this is something that is also a matter of personal taste. The remote console of Citrix Xen server seemed very sluggish to me, which made working in the virtual machine quite cumbersome. Both Hyper-V and VMWare use a similar remote console, but both did not suffer from this sluggish performance.
Citrix Xen client is a fairly new product, which is far from finished at the moment. Especially the full 3D graphics support it is supposed to deliver looks very promising. For now this 3D support is still limited to certain Intel graphics chipsets only, but other graphics chipsets and cards may be supported in the future.
But other products are also still being improved constantly and start offering additional features. Maybe this comparison should be repeated about the same time next year. It will be interesting to see if this will show major differences compared to this test.
The deployment of software packages through Active Directory software distribution, requires an MSI (Windows Installer) file. Adding this MSI file as a new package for software installation in a Group Policy Object (GPO) in Active Directory is fairly straightforward.
However, some software products don’t seem to come as an MSI file, but rather as an EXE file. For these kind of software packages we need some extra steps before we are able to add it as a new package in a GPO.
An example of such a software product is Google Earth. Recently, I was asked to prepare a software distribution for this product. This turned out to be a perfect example of a software package that needs some additional work to get things going.
Preparing the installation folder
Google Earth is an example of a software product that does not come as an MSI file, but as an EXE file instead. Before we can create a new software distribution package in a GPO, we need to extract the MSI file that is contained in the EXE file first.
There are several ways to extract the MSI file and all other files required for the installation of Google Earth, but I prefer to use an Administrative Installation.
To perform an Admin Installation of Google Earth we need to run the installation package GoogleEarthWin.exe with the /A parameter. During the Admin Installation you will be asked for a network location where the installation files should be copied to. I used the folder C:\Google\Earth_5.2 as an example, but you should enter a network folder here.
At the end of the installation wizard, uncheck the option to start Google Earth. Once the installation is finished the installation folder will contain two subfolders and one MSI file and will look similar to this:
Before we can add this MSI file to a software installation GPO, we will have to make some modifications to it. Otherwise we will get an error when adding the MSI file to the GPO:
Editing the Google Earth MSI file
To modify the MSI file, just open it in an MSI Editor. I always use ORCA for this purpose. You can obtain ORCA here.
Once ORCA is installed, just right click on the Google Earth.msi file and select Edit with Orca from the context menu. After the MSI file has been opened go to the View menu and select Summary Information. The information you will see now will look similar to this:
The problem with this MSI file is in the Languages field. This field contains multiple values separated by commas for different languages. Just remove the contents of this field and just enter the desired language id (i.e. 1033 for US English or 1043 for Dutch).
Now save the modified MSI file and try add it to the software distribution GPO again. The package should now be added to the GPO without any problems.
In small to mid-size environments I prefer to distribute all software using Active Directory and Group Policies. As soon as the computer is started, the software distribution policies will be applied and all assigned applications will be installed automatically.
When upgrading a software package to a more recent version I always select the option to remove the old version first and then install the updated version, instead of performing an in-place upgrade.
I have been using this method for quite some time and I haven’t had any problems, until now…
One of the software packages I generally install on all computers is the Sun (now Oracle) Java Runtime Environment. Previously I didn’t experience any problems while uninstalling this software, but lately the uninstall process takes forever (well, not literally) to complete.
During the software installation phase, the computer is “hanging” while uninstalling the current JRE. If you’re patient enough, the computer will eventually (after an hour or so) display the logon screen. When you log on to the computer you will not be presented with your familiar Windows desktop, but the computer seems to continue the uninstall process in the background.
Then finally, after a quite some time (again an hour or so), the user’s desktop will appear and suddenly it also becomes obvious why the uninstall process for the JRE took so damn long.
Problems uninstalling the Java Runtime Environment
In my experience there are two separate problems that can occur during the removal of the JRE software:
- The uninstall process cannot continue because one of the files is in use.
- The uninstall process cannot check the validity of the certificate used to sign a source file.
Fortunately there is a solution to both problems.
Problem #1: file is in use
When we finally manage to get the Windows desktop to show, it will display a dialog box which will indicate the file in use is jqs.exe. This file belongs to the Java Quick Starter service. During the boot sequence this service will be started before the uninstall process takes place. This results in the file being in use when uninstalling the Java JRE.
Simply disabling this service will allow the uninstall process to continue without any problems. This will slightly slow down starting Java applications, but this won’t be a big deal. On Windows Vista or above this service doesn’t have any benefits at all anyway (for more information check http://www.java.com/en/download/help/quickstarter.xml).
I have chosen to disable this service using a group policy that is applied to all computers:
Using the GPO editor, select Computer Configuration | Windows Settings | Security Settings | System Services and set the startup mode for the JavaQuickStarterService to disabled:
Problem #2: error checking certificate
The second issue involves an error while checking the validity of a certain certificate used to sign one of the source files of the Java JRE. There are possibly multiple reasons for this problem to occur, but in our case it was proxy authentication. The uninstall process runs in the context of the local system account (NTAUTHORITY\SYSTEM) and this “user” cannot be authenticated by the proxy server.
The solution for this problem involves installing the certificate as “Trusted Publisher”. Once the Windows desktop has appeared a dialog box will popup after a few seconds. This dialog box will allow you to view the certificate and it will reveal it is intended for sjremetrics.java.com. Select the Details tab and click Copy To File. This will let you save the certificate as a .CER file.
When the certificate has been saved, open the GPO editor and navigate to Computer Configuration | Windows Settings | Security Settings | Software Restriction Policies | Additional Rules. Right click the right pane and select New Certificate Rule. Use the Browse button to select the saved certificate and set the security level to Unrestricted.
After the policy has been applied the certificate will be listed as “Trusted Publisher”.
Did you ever try to get a UPS up and running on a server using Microsoft Hyper-V? Well, I did. And it proofed to be a more difficult task than I had initially imagined…
There is quite some information about Hyper-V and UPS’s that can be found on the internet, but most of this information is about connecting the UPS using a USB connection. In this scenario the server will act as a very big (and very heavy) laptop with the UPS being the battery. On a Windows 2008 server it would be possible to use the regular power options to shut down or hibernate the server when the battery (i.e. UPS) runs low.
Too bad this doesn’t apply to a Hyper-V R2 server (core) installation. On this platform it is possible to use all kinds of scripts that monitor the battery status using WMI (querying the WIN32_Battery class) and then shutting down the server when the battery is running low.
But in both cases only the server connected to the UPS will be shut down. What if there are multiple servers connected to the same UPS? This situation is quite common.
Of course one could write another script that shuts down several other servers before shutting down the Hyper-V server, but this would not be a very flexible solution.
Unfortunately, we did have another problem. Our UPS’s were not connected through USB, but through a serial cable. So all of the above doesn’t apply.
Before we migrated our physical servers to a Hyper-V based platform, we were using LanSafe to monitor our UPS’s. Despite a lot of people are always complaining that the UPS software itself is lousy, we quite liked the LanSafe software. This software did allow us to set up a LanSafe controller (server that was connected to and monitoring the UPS), several LanSafe members (servers that are shut down by the controller when the power fails) and and a LanSafe console (on a workstation) that allows the remote configuration of the LanSafe controllers. Wouldn’t it be neat to be able to use the LanSafe software again?
In order to download the LanSafe software, go to the Eaton website. Before you will be able to download the software, you will have to register first.
After registering, you should be able to download the LanSafe software. Be sure to download all required versions. Since we want to install on a Hyper-V server, you have to download the 64-bit version. But if we also need to install the software for a member that is running on a 32-bit version of Windows, you will also need the 32-bit version.
After downloading LanSafe we can install it on the Hyper-V server. But before we will start the installation, we will have to connect the UPS first. If the UPS is being detected as “New Hardware”, we can just ignore this by selecting “Don’t ask me again”. We can now run the installation program that we downloaded previously and go through the installation wizard:
- Accept the license agreement.
- Select “LanSafe Controller” to install the UPS monitoring component on the Hyper-V server.
- Select “Serial Connection (COM port)” and have the software automatically detect the attached UPS.
- Accept the detected serial port.
- If required, select the correct UPS. LanSafe supports several different UPS models and different vendors. Usually the UPS will be detected correctly.
- Enter the password for the LanSafe controller. This password is required when connecting remotely rom a different LanSafe member or console.
- Accept the default Power Failure Settings (these settings can be configured later).
- Enter a unique name for the controller.
- Skip the configuration of the SMTP settings (this can be done at a later stage).>
- Continue the installation wizard (installation folder and program group can be changed, if desired).
When the installation has finished unselect the option to start LanSafe !!! Before we can use LanSafe we still have some work to do.
Enabling the LanSafe GUI
The LanSafe GUI requires the presence of msvfw32.dll, but this DLL file is not present on a system running Hyper-V. You should be able to obtain a copy of this file from the %WINDIR%\System32 folder on a computer running Windows Vista or Windows 7.
Now copy the DLL file into the %WINDIR%\SysWOW64 folder on the Hyper-V server. That’s it…
You should now be able to start LanSafe.exe which is located in the Bin subfolder of the installation location (usually C:\Program Files (x86)\Powerware\LanSafe\Bin).
Configuring the firewall
As I mentioned before, it is quite common for a single UPS to supply power to multiple servers. In case of a power failure the controller should shut down the other servers first, before is will shut down itself. Therefor it must be possible for the controller and the member servers to communicate with each other. The problem is that the firewall blocks the ports that LanSafe requires for its communication. We need to enable these ports first.
The ports that LanSafe uses are UDP ports 3068, 3069 and 7015. To enable communication through port 3068, type the following commands in the command windows at the Hyper-V server:
netsh advfirewall firewall add rule name="LanSafe (UDP 3068)" protocol=udp localport=3068 dir=in action=allow
netsh advfirewall firewall set rule name="LanSafe (UDP 3068)" new enable=yes
Repeat the commands above for port 3069 and port 7015. When done, communication between the LanSafe controller and the LanSafe members / consoles will be possible.
Shutting down physical servers during power failure
When we would like the LanSafe controller to shut down other servers attached to the same UPS as the controller, we will need to install the LanSafe software on these servers as well. Depending on the type of Operating System on the server, we will either need to download the 32-bit or 64-bit version of the LanSafe software.
Run the appropriate installation package and go through the installation wizard:
- Accept the license agreement.
- Select to install a “LanSafe Member”.
- Enter the name of the controller that should be managing this member.
- Skip the configuration of the management settings. These settings can be configured later.
- Select a destination folder and a program group.
- When the installation is completed, LanSafe can be started.
After starting LanSafe it is required to enter the password of the controller. This is necessary to prevent unauthorized members to connect to the controller.
The shutdown timings for each member as well as the controller itself, can be configured through the Management Settings using the LanSafe GUI.
Shutting down the virtual servers on the Hyper-V server
Using virtual servers makes it very easy to shutdown a server, or even suspend a server. In fact, the latter is the default setting in Hyper-V. As soon as the physical Hyper-V server is shut down, all virtual server running on the Hyper-V server will be suspended.
If desired, it is also possible to automatically shut down all virtual servers. In that case one would have to select the bottom option in the Hyper-V management console.
UPS’s connected via USB or LAN
Although the information above is about using a serially attached UPS with Hyper-V, the LanSafe software also supports UPS’s connected via USB and UPS’s connected via the LAN using a network card inside the UPS. I have not been able to test these configurations myself. I know that the LanSafe software also contains drivers for USB connected UPS’s (you’ll have to extract these drivers from the installation program first). You will probably need to install these drivers on your Hyper-V server first, before attaching your UPS.
If you can confirm this from your own personal experience, then please leave me a comment.