No matter how many useful applications come bundled with Ubuntu, it's difficult to live without some Windows programs, particularly if you work in an industry where, say, Word, Excel or Photoshop compatibility is a must. Luckily, it's entirely possible to run many Windows applications within Ubuntu using an optional package, Wine.

Wine is frequently described as an emulator, but in fact it works as a " compatibility layer" offering Linux-based alternatives to the libraries that Windows applications call on during use, and a process — the winerserver — that translates the functions of the Windows kernel and UI into their Linux equivalents. Using these and some clever jiggery-pokery with file systems, Wine convinces Windows apps that they're running on a Microsoft OS and enables them to run happily on Ubuntu with a minimal performance hit. The good news is that it's usually easy to use. First, you need to install Wine: search for it in the Ubuntu Software Centre, or download the latest version from

Now, it's time to install your Windows app. Just download the file or insert the CD or DVD, and you can often doubeclick on the standard Windows installer (or let the CD autorun) and install an application just as you would in Windows. Wine handles the whole thing for you, practically transparently. Nor is there any hassle in running installed software: you can either run the application from a desktop shortcut or from Applications I Wine 1 Programs.

Sadly, Wine doesn't always flow smoothly, and not all applications work perfectly first time. Some just won't work whatever you do, while others rely on security systems that scupper Wine. Others will work, but with limited functionality, woeful stability or significant bugs. On the plus side, maintains a database of Windows applications, with volunteers testing new software as it appears, and grading them from Platinum (runs flawlessly out of the box) to Garbage ( won't work at all). Office 2007 and Word 2007, for example, are rated as Silver and will work for most English-language users straight away. InDesign CS3 and CS4, however, are listed as Garbage, although they may install and run as part of an Adobe Creative Suite.

It's important to note that these findings are dependent on who and how many people have tested, and that your mileage will vary. For example, the Office 2010 32-bit installer is currently listed as Bronze, while Word 2010 is listed as Garbage. However, we've had people within the PC Pro office comfortably using Word 2010 within Ubuntu.

Meanwhile, you'll find some games listed as Platinum, then struggle for hours to get them working in Ubuntu. It's also entirely possible to find applications that will fail on your first attempt to install, but succeed on the second for no real reason. Overall, however, the WineHQ database is a fairly reliable guide, and worth consulting if you need to use a specific application.

What can you do if Wine doesn't work? Well, there are some useful tricks you might want to deploy. First, it's possible to configure Wine to behave like a specific version &Windows, by going to Applications I Wine I Configure Wine, clicking the Add Application button to add a Windows application to the list, and then setting the Windows Version using the dropdown menu at the bottom of the screen.

In some cases, you can also use the Graphics settings tab of the Wine Configuration menu to either start the application within a virtual desktop or switch off Direct3D hardware support. Of course, doing so might make some applications, notably games, virtually unusable. There are also Wine plugins, such as the incredibly useful Winetricks script, which install additional Windows libraries and ensure maximum compatibility.

Some of these are integrated into the default Ubuntu Wine installation or the latest version downloadable from WineHQ – but don't take anything for granted. You can see more detailed instructions at http://wiki. If you're planning to run games then give the PlayOnLinux application a try. This acts as a front-end for Wine and incorporates a range of Wine scripts and additional Windows libraries, all in aid of getting as many games as possible to run. It also supports Valve's Steam client, allowing you to persuade a number of games that you may have already purchased on a Windows PC to run within Ubuntu using Wine. Making heavier use of graphics and audio hardware, games can occasionally be challenging to get working, but the WineHQ apps database offers excellent support.

Most of all, remember that the WineHQ database contains a mass of information, and that Google is your friend. With so many Ubuntu users trying to get Windows applications to work, it's likely that someone will have encountered the same difficulties as you and – hopefully found a way to solve them.

Understanding Windows 7 Setup Process

In comparison to Windows XP, there are numerous differences in the deployment technologies that are now available with Windows 7 as new and improved tools have been developed based on technologies that were first introduced with Windows Vista. Before Windows Vista was released, Microsoft did not have robust tools to facilitate mass deployment. If you are unfamiliar with Windows Vista or your organization passed on it altogether, you might as well unlearn everything you know on Windows XP deployment and start from scratch.

Before we are able to prepare for volume deployments of Windows 7, it is important to understand the underlying processes of the installation so that we make the best use of the tools. There have been significant changes to the way the Windows operating system is now deployed. Let us first glance at the following list of things that have changed in deploying Windows since the Windows XP days:

» Booting up the Windows installation occurs through the Windows preinstallation environment (Windows PE), which replaces any DOS-based boot disk/media.

» Windows Setup is now a file-based image deployment.

» Installation source files may be 2 GB or higher.

» All Windows installations need to be activated.

» The Boot.ini is no longer used for boot configuration.

» Setup.exe is now the new command that launches the Windows installation process, replacing winnt32.exe.

» The Windows installation is independent from the Hardware Abstraction Layer (HAL.dll).

» Windows 7 is not language specific, whereas for Windows XP/2003 or earlier each language had its own build of the operating system. Languages are now separate packages.

» The Windows 7 DVD contains the source Windows Image (WIM) file containing all of the editions of this operating system’s version. The installer determines which product to install based on the license key.

The Windows 7 installation is now conducted through file-based images. What comes to mind when we talk about “imaging” is what in the industry is more commonly known as sector-based imaging. Numerous administrators have probably worked with third-party utilities for imaging such as Symantec Ghost ( or Acronis TrueImage ( to take snapshots of a system volume in order to capture the desired system state and installation. The images these products capture are different from the WIM file format that is file-based. The main difference is that sector-based images copy indiscriminately sector-by-sector at a low level from a hard drive to build a snapshot of storage volume; file-based images such as WIM images are captured by taking snapshots at a higher level of files and folders. The bottom line is that even though sector-based images are very flexible because they can ignore the type of file system in use, they are somewhat unpractical to maintain and manage; in order to modify and edit a sector-based image, it would require deploying the image, making the changes, and recapturing it. In the case of WIM files, the action to modify and update the images can be performed by instantly “mounting” the captured image, applying the changes at the file system level, and then committing the changes immediately.

The image-based Windows setup process that was first introduced with Windows
Vista greatly facilitates the deployment of the operating system to disparate hardware architectures without requiring building separate installation packages/images. This same behavior can also be found in Windows 7, and it may come as good news to some administrators who did not have much exposure or were unable to deploy Vista. The way the new Windows 7 setup is designed streamlines many portions of previous operating system installations that would usually encounter obstacles when being deployed, especially from captured images.

There were many limitations when Windows XP images were deployed as these would not necessarily restore successfully on to any computer with a hardware architecture different than that of the system from which the image was captured. This created a lot of additional work for system administrators, including managing multiple images and developing custom scripts to force things to work properly. Important system components such as the HAL were tied to the specific installation device and would usually require additional steps/tools to allow a restored image to be reconfigured properly. Some of the known issues for Windows XP images include the following:

» The imaged computer is expected to boot from the same storage controller as the reference computer.

» The imaged systems need to use the same HAL as the reference computer.

» The sector-based imaging process is destructive; thus, it replaces all contents of the destination computer and could complicate some Windows deployment scenarios including in-place upgrades and other types of migrations.

» Maintaining the image to include updates and new applications was time consuming as directly modifying the image was not possible.

» The need for third-party imaging utilities that incurred additional licensing, training, and operational costs.

Windows 7 has several editions; however, all editions of Windows 7 use the same installation image (install.wim which may be found in the Sources folder of the installation media). What varies is that Microsoft packaged media that is specific to one edition, which means that if the setup is executed image from which the setup is based. Depending on the need of a particular system/user, the deployed OS can be any of the needed editions, and it will be installed without the need for additional source files. normally, it will allow the installation of just the edition that was purchased through the user interface; nevertheless, by using the unattended setup answer file (unattend.xml), it is possible to install any edition (provided that there is a license key available). By knowing this it is easier to understand that despite the many flavors of Windows 7, there is a universal

Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010

Deploying Windows 7 in an Enterprise Environment - Deployment Scenarios

The deployment scenarios are the following: upgrade (in-place), new installation, refresh, and replace.

Upgrade Scenario
This scenario allows an installation of Windows Vista Service Pack 1 (SP1) or later to be upgraded to Windows 7 while preserving the user state and all transferrable settings and files, as well as maintaining the installation of existing applications. As discussed in the previous chapter, there is no direct upgrade path for Windows XP, and therefore, the refresh method must be used (which keeps files and settings but not installed applications). This deployment method is also assessed by the Windows Compatibility Wizard, which helps determine if any components need to be individually addressed before performing the upgrade.

Performing an upgrade may be one of the easiest and least complex methods for deploying Windows 7; however, there is a certain risk attached to this operation as all settings are imported “as-is” from the earlier version and the administrator does not have much control on what gets transferred. Unless the state and condition of the system are known, it may be preferable to opt for a scenario that allows for selectively preserving the settings.

New Installation
The new installation involves deploying a clean copy of Windows 7 on the target computer through a straightforward setup process. It is assumed that the hard drive and system volume have been properly partitioned and formatted. This type of installation will deliver the most consistent result because all settings are either the setup defaults or set by the administrator.

Refresh Scenario
Similar to the new installation, the refresh scenario contemplates performing a clean setup with the difference being that the target computer already contains a Windows operating system for which files and settings will be preserved (note that as a difference with the upgrade method, the installed applications are not taken into consideration). This scenario is especially useful in the event that preserving the user state is a priority as it still leverages the benefits of consistency that come through a new installation. This scenario can be automated with the latest version of the User State Migration Tool (USMT 4.0), which will collect the pertinent data for each user state found in the system and consequently restore it after the clean installation is performed.

Replace Scenario
This is very similar to the refresh scenario except that the target system is a new computer, which does not contain any files or settings. The scenario consists of conducting a new installation on the target computer, and then using the USMT 4.0 to transfer files and settings from the old computer. This scenario can be run side-by-side with an older system running Windows XP or Windows Vista.

Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010

Deploying Windows 7 in an Enterprise Environment overview

In a nutshell, the deployment process intends to get Windows 7 on the specified target computers. Whether it is being installed on one or many systems, the general approach would be as follows:

» Prepare to build master installation – This step encompasses setting up a technician computer with the necessary tools, Windows 7 source files, applications, device drivers, and additional software packages. In this step, you would also prepare the setup automation by creating answer files and configuring a source distribution share.

» Build, test, and capture image of master installation – You will designate a reference or master computer in which you will use the answer file that was previously generated to run and test the Windows 7 installation from the distribution share and ensure that the setup automation works properly. After setup is complete, you can perform the necessary customizations to meet the needs of your business. Once you are satisfied with the master installation, you can then prepare it for duplication and thereafter capture your progress.

» Prepare deployment media and network distribution – In this step, you will make the captured image available on a network share that may be accessed by the destination computers to which the image will be deployed. Alternatively, the images may be stored on other media including a DVD, an external mass-storage device, or Windows Deployment Services (WDS).

» Run setup/transfer images on to destination computers – By accessing either the network share or the prepared media, you ultimately will deploy the prepared source media to get Windows 7 on the target computer.

Source of Information : Syngress Microsoft Windows 7 Administrators Reference Jun 2010

Cloud storage is for blocks too, not just files

One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...