So i made a clone of a CentOS vm and imported it in another environment of me and it looked great until i tried to configure my nic. Somehow i ended up with two eth0 files.

After zooming in on this issue i saw that i had an ifcfg-eth0 and an ifcfg-eth0.bak file in /etc/sysconfig/network-scripts!! Why?

The only difference between both files was the MAC address, hmm maybe this was causing the recreation of this file?

Well i did a little search on the internet and found all kinds of articles but couldn’t find a simple solution for this problem.

VMware has a nice article explaining howto avoid MAC changes and / or manually assign a MAC addres, http://www.vmware.com/support/ws55/doc/ws_net_advanced_mac_address.html, but this is not what i want. Because this cloned vm will be installed in different environments and this will have a MAC change. Setting a static MAC isn’t the solution either.

When i found some articles about Kudzu i felt that i was going in the right direction.

During boot Kudzu detects a MAC address change and creates the ifcfg-eth0.bak file! This behaviour is normal because in my case VMware Workstation gives the NIC a new MAC address.

Some articles describe a way to disable Kudzu but i don’t think that’s the solution because Kudzu detects new hardware and hardware changes en CentOS (and Redhat). In newer versions Kudzu is removed by the way.

Removing the ifcfg-eth0.bak by typing rm -f /etc/sysconfig/network-scripts/ifcfg-eth0 is an option but the file is recreated the next boot by Kudzu.

It’s also possible to reconfigure the ifcfg-eth0 and the /etc/hosts, /etc/resolv.conf to get everything working again but why do all this when there is an easy solution to solve it.

If we look at the /etc/sysconfig/network-scripts/ifcfg-eth0 we can see the HWADDR line which holds our MAC address.

If we remove the complete HWADDR line just before shutting the vm down and exporting it we won’t end up in having an ifcfg-eth0.bak file in a different environment.

This easy workaround solved this issue in my environment.

Instead of creating two different Microsoft Word 2010 applications with both the 32bits and 64bits installation path i will describe how to create only one application which changes the installation path automatically for you.

This automatically change will be based on a Zone which checks the client on Operating system bit version and changes the installation path with an Environment Variable.

Let’s look at the different installation paths we are dealing with.

The 32bits Windows 7 has Microsoft Office 2010 installed in the c:\Program Files\Microsoft Office\Office 14 directory:

And the 64bits Windows 7 has Microsoft Office 2010 installed in the C:\Program Files(x86)\Microsoft Office\Office14 directory:

Because the major difference is the Operating system bit versions, we start with creating a zone which is able to detect the Operating system bit version of the client.

In this step by step guide we use this Zone to place an Environment Variable in the application path of an application but this Zone can also be used for other settings based on Operating system bit version.

In the RES Workspace Manager console just go to Context and then to Locations and Devices and click on Add. When the Add/Change Zone screen is shown give the Zone a name like on the following picture:

Now click on the Rules tab and create a Rule by clicking on Add. Now choose Operating system and then click on Bit version like on the following picture:

On the next screen leave the Operator on = and change the Filter to 32-bit Version, like on the following picture:

Now just click on OK and again on OK and we will end up with a Zone which is able to sort clients on Operating system bit version.

The next step is to create the Microsoft Word 2010 application.

It doesn’t matter on which Operating System you create it because in this guide the application path will be changed to a variable.

In the RES Workspace Manager console go to Composition and then go to Managed Applications and click on Add. Now choose application because we are creating an application.

It’s also possible to import an application but in this article we will describe the manual creation of a new application.

Now click on Command line field and a browse button will appear on the right and click on the browse button to find the Microsoft Word 2010 executable.

The default installation path of Microsoft Word 2010 on a Windows 7 64bits client is C:\Program Files(x86)\Microsoft Office\Office 14\ , please browse to this location and select WINWORD.EXE.

RES Workspace Manager will fill in some fields automatically for you.

Now we have Microsoft Word 2010 in the RES Workspace Manager console we immediately add the variable name. Change the Command line and Working directory to the shown values on the following picture:

Now click on Access Control and change it from Administrative Roles to All users and press OK.

By default the Access Control of a new application is set to Administrative Roles. This prevents you from publishing an unconfigured application directly to your users.

The last step is to create the variable. Go to Composition, Other and then to Environment Variables. Click on Add to create a new Environment Variable.

On the Change environment variable screen add the values shown on the following picture:

This will look for the %ProgramFiles(x86)% variable and change it to the %ProgramFiles% value. But because we only want this to happen for our Windows 7 32bits clients we need to point it to the Zone which we created earlier. Do this by clicking on Access Control and Add the 32Bits Zone like on the following picture:

Now click on OK and try to start Microsoft Word 2010 on both the Windows 7 32bits and Windows 7 64bits client.

But something strange happens when Google Chrome is installed. Where is Google Chrome installed exactly?

Nothing can be found in the %ProgramFiles% or %ProgramFiles(x86)%, neither in the %AppData% directory.

Google Chrome installs itself in the Local AppData of the userprofile. Google could have a good explanation for it but this makes it very difficult to use Google Chrome in an environment with roaming userprofiles.

There are several hacks floating around on the web to make Google Chrome work with roaming userprofiles but aren’t easy to perform and could cause troubles.

The best solution for this is to use the Google Chrome standalone installation msi, which is a bit hard to find but can be downloaded from here.

When this version of Google Chrome is installed the executable can be found in the ”C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” directory, like shown on the following picture:

Before we publish this application we are going to focus on what Mozilla Firefox does exactly in the userprofile and registry.

Like any other application Mozilla Firefox creates some user specified registry settings and profile directory’s. After starting Mozilla Firefox for the first time the %AppData%\Roaming\Mozilla directory is created which has the most important data in it for Mozilla Firefox.

The default size of this directory is around 13MB which is quite large and could cause some  troubles in large environments when Roaming Profiles are used.

Imagine that aside from the profile size of the user which could be very large, the 13MB of the Mozilla Firefox profile will also be roamed when logging on and off which could cause a delay for all the users during logon.

A good workaround for this issue could be the user of a Mandatory Profile, but with the use of a Mandatory Profile the profile will start from zero after a new login. So all the personal settings of your users will be forgot after a new logon and could cause your users to get upset.

In this article i will describe how to publish Mozilla Firefox with RES Workspace Manager and have the personal settings saved using User Settings Templates.

RES Workspace Manager provides a set of pre-defined templates for the most populair applications. This list gets updated very often and therefore At the moment RES Workspace Manager has User Settings Templates for the most used applications and the list gets updated very often.

It’s also possible to create User Settings Templates yourself but i will describe this in another post.

So if we choose the User Settings Template for Mozilla Firefox and zoom in on it we can see that the %AppData%\Mozilla\Firefox\profiles.ini and the %AppData%\Mozilla\Firefox\Profiles are pre-defined. This is enough to remember the user specified settings for Mozilla Firefox.

As you can see you are free to add registry locations or folders to this template to expand the scope of this template. You can do this by clicking on Add, for this article it isn’t needed to add extra settings to this template.

If we add the User Setting Template to Mozilla Firefox we will be sure that all the user specific settings will be remembered for the users who have access to Mozilla Firefox.

In the beginning of this article we saw that the default Mozilla Firefox profile is quite large, around 13MB. After enabling this User Setting Template the size of the Mozilla Firefox profile is reduced to around 80KB! which is a very large reduction in size making the Mozilla Firefox profile usable in any environment!

In the next article we will describe how to create a custom User Settings Template for an application.