Adding multiple network adapters to linux guest virtual machine (VirtualBox or VMware)

Title: Adding multiple network adapters (NIS | network interfaces) to linux guest virtual machine (VirtualBox or VMware)

I came across a situation where I would like to have dual network interfaces in a CentOS guest virtual machine so that the VM can have dual IP addresses.

I have figured out the way to achieve this in CentOS, but this can be easily extended to other type of Linux boxes. This is done in Oracle VirtualBox, but it would be very similar if you use VMware tools.

Meanwhile, I only tried Bridged Adapter. But it should be similar if you use NAT.

1. Add a virtual network adapter in Oracle VirtualBox:

2. Reboot the VM.

3. Go to /etc/sysconfig/network-scripts/. You will see ifcfg-eth0 only, because the config script for the extra network cards are not created automatically. Now you need to manually create the script for the 2nd network card (NIC, network interface, network adapter, whatever you prefer to call it).

4. cp ifcfg-eth0 ifcfg-eth1 . Now you can edit ifcfg-eth1 to contain the values. Take a look at this file first.
DEVICE=eth0
TYPE=Ethernet
UUID=3b594564-4088-4gfd-a4a6-5462e7b3fbde
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp
HWADDR=08:00:12:53:62:CD
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"

4 lines to change:
DEVICE; UUID;  HWADDR;  NAME

DEVICE: increment the device ID so that it looks like this:

DEVICE=eth1

UUID: a utility called uuidgen can generate UUIDs, and this is not limited to network adapters. Use the output to revise the UUID line.


HWADDR: this is the MAC address of the network card. There are at least 3 places you can find the MAC address.
(1) when you enabled the network card in Oracle VirtualBox, the MAC address has been created, you can see this address in the picture above, see "MAC Address".
(2) Run command ip link show, you will see the list of network interfaces.
(3) Go to /sys/class/net/eth1, the MAC address for eth1 is held in the file 'address'.
Now you have this information, you can update this line.

NAME: increment the number accordingly. In this case it will be  "System eth1" .

5. Restart the network service: sudo service network restart
You should see both NIC get started successfully.
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
Determining IP information for eth0... done.   [ OK ]
Bringing up interface eth1:
Determining IP information for eth1... done.   [ OK ]

If error, trouble shoot. You might have a typo somewhere.


Note that I am using DHCP in my case, you might need to adjust the network scripts accordingly if you need static address. There are plenty of tutorials on setting up static IP.

Install wordpress on Redhat/CentOS like systems for development

Use CentOS as example.

When I installed CentOS virtual machine, I chose basic server rather than web server, because I'd have to do lots of extra configuration, and turn off tomcat etc. anyway. It's not a big deal to install apache and mysql. So I started clean.

-- CentOS installation

1. During installation, use static IP address rather than DHCP dynamic IP. Because I am going to use a GUI-less server, and I am not going to bother with DNS configuration (so that hostname can be resolved to IP).
2. Turn off SeLinux. Too much complication using selinux. So I turned it to permissive by editing /etc/selinux/config, set SELINUX=permissive.
3. Turn off firewall. Are you good at configuring linux firewall? I am not. Leave the firewall on will cause the webpage inaccessable outsife of my linux server. So I turned it off by   sudo chkconfig --level 23456 iptables off
4. Edit /etc/hosts, add the entry for my server, it looks like this  192.16.1.10  webbox webbox.Replace webbox with your server name. Note that I am running this linux box as an isolated test box, hence I am not putting in the FQDN. Just the hostname will do.
5. Reboot.

-- Install Apache and MySQL.
This instruction https://www.digitalocean.com/community/articles/how-to-install-wordpress-on-centos-6--2 is pretty clear already.

Also need to install php mysql extension:
yum install php-mysql
service httpd restart

A few things to change in the /etc/httpd/conf/httpd.conf:

1. Line #Listen 12.34.56.78:80: change the IP address to my linux box IP. (remember to un-comment it).
2. Line ServerName www.example.com:80: change it to ServerName 192.168.1.10 (Remember to uncomment it) I chose not to specify port number. It will do the job.

Run sudo service httpd restart
Test the web server by browsing to http://192.168.1.10
You should see the welcome page of Apache. If not, trouble shoot.

I could then run the wordpress installation by opening http://<ip address>/wordpress/wp-admin/install.php

-- Install phpMyAdmin

• Add EPEL repository the system.

CentOS/RHEL 6, 32 Bit (i386):
# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

CentOS/RHEL 6, 64 Bit x86_64):
# rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

• Install phpMyAdmin.

# yum install phpMyAdmin

• Configure phpMyAdmin for remote access.

Edit /etc/httpd/conf.d/phpMyAdmin.conf and update all 127.0.0.1 with my IP.

• Access phpMyAdmin in a browser.

URL: http://192.168.1.10/phpMyAdmin

Installing xdebug on RedHat based Linux, and use it in NetBeans IDE

I battled with xdebug for 2 hours before I finally installed it successfully.

Now. Installation.

If you want to download and compile xdebug from source, walk away now. I installed the binary directly.

The best way to install it on a redhat or sister systems (e.g. CentOS) is to use pecl. Run the following to see if you have it on your system:
 which pecl

If not installed, sudo yum install php-pear , pecl is included in this package.

I then ran
 sudo pecl install xdebug

This might work for you. But in my case it failed cos it cannot find phpize. If this happens to you, install php-devel.
 sudo yum install php-devel

Also, on one server, pear was configured to use an invalid proxy. Because of that, pecl cannot find xdebug. To resolve this issue, run this to list the configurations:
  pear config-show

Then unset the proxy:
  pear config-set http_proxy ""

You can now check if pecl can find xdebug:
  pecl search xdebug

After this, you can try install xdebug again and it should pass. Have a look at the output in the terminal, you need to make use of the installation path.

Next is to edit the /etc/php.ini to include a line like this, use the path you have noted down:
 zend_extension=<your/path/to>/xdebug.so

I also added the following lines for xdebug:
xdebug.remote_enable=1
xdebug.remote_host="127.0.0.1"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
xdebug.remote_mode=req
xdebug.profiler_enable = 1
xdebug.scream=1
xdebug.profiler_output_dir = "/tmp"

All the guide I saw stopped here, sort of. I then tested it out, just to find it not working. What I did not realise is that the pecl install does not set correct permissions. Now chmod to your xdebug.so, set it to
 -rwxr-xr-x. 1 root root  787575 Jul 26 18:07 xdebug.so

It now should be OK.

But still, we need to test.

Here is something I found on the net: create a file, say, test.php,
<?php

function test(){

echo "Called @ ".xdebug_call_file().

":".xdebug_call_line()." from".

xdebug_call_function();

}

test();

?>

cd to that directory, 

  php test.php

you should see something like: Called @ /var/www/html/test/index.php:13 from{main}

You see this, you are all set. Otherwise check you configuration. In my case, when I copy paste in the line in php.ini, I missed the leading character. That took me a while to find out...

NetBeans needs a bit configuration, too. The main guide can be found in the netbeans official tutorial. There is one further tweaking to do:

Just below the top menu bar, you will see a drop-down list, which defaults to <default>. Click on it, choose Customise.

Wala, now you see the project properties. Project URL, Index file, Arguments are the useful ones to know at this stage. You will need to control which page you want to start with.

Windows 7 Deployment - Part04: Create MDT Deployment Task Sequence For Deployment (2)

prevous<< Back to Index >>

Now, we know how to add applications, OS, device drivers, and create task sequence.

There are more things to configure to get things working. Open the MDT deployment share properties.

Choose the hardware architecture you need to support.

Click on Rules tab. This opens the CustomSettings.ini file for you. The default settings look like this.

Edit the settings, change them like below. Note: do NOT try to be 'organized' by adding comments for blocks, e.g. [locale settings], [Time zone], unless you know what you are doing. MDT does parse the block names during deployment. Blindingly add such comment in may lead to undesired effects. Just keep it simple, only type in what is needed.

The key thing here is ApplyGPOPack=NO. If this setting is omitted, MDT 2012 will do some match-making  behind your back. If it detects your OS to deploy is one of 4 popular types, it will apply default group policies to your new machine - Windows 7 is one of the 4. This can lead to lots of troubles further down the road.

If you put ApplyGPOPack=NO in here, all task sequences you have in this deployment share will be affected.

You can also skip/disable local GPO application through task sequence properties (then do not have this line in the CustomSettings.ini file). In that way, the setting only applies to this task sequence. Go to your Task Sequence properties, you can see Apply Local GPO Package is the last step in State Restore.

You can check the reference for all the rest of the settings. Some of the settings must be all present to make a page skipped.

In this example, I am running the test in a Workgroup environment. To skip the credential page, I have provided UserID and UserPassword settings, without UserDomain setting. If you are doing this in a domain environment, you should provide the UserDomain setting as well.

Meanwhile, if you are putting in domain credentials, then you simply enter your domain user name for UserID. If you are doing it in a Workgroup environment, you should put your machine name in as well, e.g. 

  UserID=test-bench-PC\fishismyname

However, you need to make decision again regarding security and efficiency. the password you entered here will be in plain text in the answer file. I tend to leave these settings out, and manually key in the network credentials on each machine I image. 2 reasons for this: (1) security, the obvious reason; (2) domain passwords always change, due to the password policies adopted by most organizations. You will have to update UserPassword every time you change this password. So, you will need to put in some effort one way or another, so why not go with the more secure option. However, if you often need to image lots of machines in one go, then you might still want to consider the automated way.

A working setting is listed below. This will skip quite a few pages during installation. Add in your own values where I took mine out, and make adjustment for your system.

[Settings]

Priority=Default

Properties=MyCustomProperty

[Default]

OSInstall=Y

SkipCapture=YES

SkipAdminPassword=YES

SkipProductKey=YES

SkipComputerBackup=YES

SkipBitLocker=YES

SkipBDDWelcome=yes

SkipUserData=YES

SkipProductKey=YES

ProductKey=

SkipTaskSequence=YES

TaskSequenceID=

SkipTimeZone=YES

TimeZone=085

TimeZoneName=GMT Standard Time 

SkipLocaleSelection=YES

InputLocale=en-GB

SystemLocale=en-GB

KeyboardLocale=en-GB

UILanguage=en-US

UserID=

UserPassword=

ApplyGPOPack=NO

Now, if you look at the bottom of this page, you will see a button called Edit Bootstrap.ini.

Click on it to open the file.

Some settings must be put in here as well to skip a page. Like the one I did here, together with CustomSettings.ini we just edited, we can now automate the locale selection page, and the network credential page. If we do not put them in bootstrap.ini file, those pages will still appear. Check the reference if in doubt.

With all these settings, you have finished setting up a deployment share. There are still 2 issues remaining.

Format the disk and create disk partition.

If you don't configure this (leave things as default), your deployment process will not erase the machine. This will lead to undesirable effects.

You can configure this in the task sequence properties page - this is to show you where to open the page. Nothing is configured yet. However, do please note that this group of tasks are for new computer only, if you check New Computer Only properties, you will see there is a check on DeploymentType=NEWCOMPUTER variable. If you have DeploymentType=NEWCOMPUTER in your CustomSettings.ini, then Format and Partition Disk will be performed, otherwise skipped. If skipped, MDT will use the info provided in <DiskConfiguration> section to do the format/partition. If not skipped, what you put in <DiskConfiguration> section will be ignored.

Either way will work.

In this case, I am not going to add DeploymentType=NEWCOMPUTER in my CustomSettings.ini file, I am going to use unattend.xml to control the disk format and partition instead.

Go to the deployment share folder, under Control folder, go in the folder that bears your task sequence name, open up the unattend.xml.

Add the following near the top, just before <ImageInstall> tag. The following will create 2 partitions. Note that Windows will create a secret partition. You will not see this drive in Windows Explorer when the machine is imaged (you can see it in disk management). You might have noticed this secret partion when you use ImageX to capture your custom windows image - after boot into WinPE mode, if you go through each drive, c:, d:, f:, g: and so on, you might notice that under c:, if you run dir, Windows files are not present. If you go under d:, and do a dir, you will see the familiar files structure, Program Files, Program Files(x86), Windows, etc, etc.. That little c: is the secret, reserved, disk partition created by Windows 7.

            <DiskConfiguration>
                <Disk wcm:action="add">
                    <DiskID>0</DiskID>
                    <WillWipeDisk>true</WillWipeDisk>
                    <CreatePartitions>
                        <!-- System partition -->
                        <CreatePartition wcm:action="add">
                            <Order>1</Order>
                            <Type>Primary</Type>
                            <Size>300</Size>
                        </CreatePartition>
                        <!-- Windows partition -->
                        <CreatePartition wcm:action="add">
                            <Order>2</Order>
                            <Type>Primary</Type>
                            <Extend>true</Extend>
                        </CreatePartition>
                    </CreatePartitions>
                    <ModifyPartitions>
                        <!-- System partition -->
                        <ModifyPartition wcm:action="add">
                            <Order>1</Order>
                            <PartitionID>1</PartitionID>
                            <Label>System</Label>
                            <Format>NTFS</Format>
                            <Active>true</Active>
                        </ModifyPartition>
                        <!-- Windows partition -->
                        <ModifyPartition wcm:action="add">
                            <Order>2</Order>
                            <PartitionID>2</PartitionID>
                            <Label>Windows</Label>
                            <Letter>C</Letter>
                            <Format>NTFS</Format>
                        </ModifyPartition>
                    </ModifyPartitions>
                </Disk>
                <WillShowUI>OnError</WillShowUI>
            </DiskConfiguration>

For reference, see http://technet.microsoft.com/en-us/library/ff716466.aspx

Copy profile.

This setting triggers the deployment process to copy the profile you have on the reference machine to the new machine.

Set CopyProfile to true in the node high lighted in grey, as shown above. Use the key words in red circle to locate the position.

Now, right click on the MDT Deployment Share -> click on Update the deployment share, the relevant files will be updated or created.

McAfee users must note: it is best to disable On-Access scan before you do the update. It will SERIOUSLY slow down the process. On my machine, it takes 40 minutes with On-Access scan on, only about 5~10 when off.

OK. We are nearly there.

Go to the Boot folder in your deployment share folder, LiteTouchPE_x64.iso is what you need. Use any tool that can unpack ISO files, 7-zip for instance, and copy the content of the iso image into your bootable USB pen drive. You can now boot your new machine using this USB drive, and the Lite-Touch installation will begin.


Windows Updates

There are 2 Windows Update steps built-in each task sequence. Look in your task sequence properties -> State Restore, you will find them. They are disabled by default. If you want windows update automated, go the Options tab on the right, un-tick the 'Disable this step'.



Multiple machine models

To accommodate different machine models, one approach is to create a new deployment share for each model, so that that series of device drivers can be applied.


Automate Application Deployment

The draw back to this solution is that, say, you have 10 applications to be deployed, you need to go through the creation process for each single deployment share. It's not just application creation. It's about maintenance, too. If, say, you are moving to Office 2012 from 2010 in your organization, and you have 20 Deployment Shares, you will need to do the update 20 times.

There are ways to avoid this. One option is to leave application silent installation to Active Directory, if you have one. After the machine is imaged, the PC can be moved (or moved as part of the deployment process) into the relevant group, and one GPO should be silent installation of Office 2012. In this way, you only have 1 place to maintain. Or you may have other 3-rd party tools to push applications out. There is always more than 1 way to skin a cat. Check what are available to you.

You can further fine tune the task sequences. I will share the tips when time permitting.

.prevous<< Back to Index >>

Windows 7 Deployment - Part03: Create MDT Deployment Task Sequence For Deployment (1)

previous<<   Back to Index   >>next

MDT is often used in conjunction with WDS, Windows Deployment Service, for Windows deployment. Using WDS, we can boot a machine from on board NIC, choose a deployment sequence and kick start the process. Note: WDS needs to be installed on an Active Directory Domain Controller, and the DHCP must be configured, too.

However, if you somehow cannot have WDS, e.g. you are in a Samba domain without AD domain controllers, or you do not have much access right to your AD Domain Controller in your small branch, or even, you are not comfortable installing WDS on the AD domain controller and change DHCP settings, you can perfectly live without it. A few bootable USB pen drives will do the job equally well.

We are going to see how to use MDT 2012 and a few USB pen drives to do Windows deployment.

Now start Microsoft Deployment Toolkit -> Deployment Workbench.

Create a new deployment share as shown below.

Click Next until you hit the Options page. What you choose depends on your need. Normally we will be imaging a new machine, so we un-tick all of them.

Click through, and hit the Finish button.

Now, the real job begin.

Add WIM image.

Expand MDT Deployment Share, right click on Operating Systems -> Import Operation System. Some organization can go with the Windows 7 ISO image. In my case, I am going to use a customised WIM image as captured in part 02 using ImageX, so I need to select the 2nd option, Custom image file. Browse to your WIM file, e.g. image.wim, click through the pages.

Add Applications

I am going to use 7-zip as example.

Right click on Applications on the left pane -> New Application -> Next -> enter the information as desired,

Next page, browse to where the .MSI resides. Click through the pages until you see the command details page. Enter the command line as shown below. Check references for different software packages. Some comes with instructions for its own silent install switches. Some does not, but complies with the standard conventions.

Click through pages, and you are done.

Add Device Drivers

You can see Out-of-box Drivers on the left pane. This option provides the most convenient way of 'injecting' device drivers. However, the drawback is that this options is 'global'. You cannot pick and choose during deployment. If you only need to support 1 computer model, this is fine. But most likely you have different hardware to support, then this approach is not very suitable (unless you create multiple deployment shares, each for 1 model, or a few closely related models).

Now extract the drivers under c:\drivers. 

Right click Out-of-box Drivers -> Import drivers -> browse to the driver folder, click through the pages, and finish.

Create Task Sequence

You should be pretty familiar with the layout by now to create a new task sequence - start from right click on Task Sequence to create one. Put in a name and ID as desired.

Use the default - Standard Client Replace Task Sequence.

In a real case, you might have a list of WIM files to use. You need to select the one you want for the current task sequence. In this example, I only have one.

Choose the right key option. In my case, I leave it out.

Provide the PC owner's name and organisation name.

Now, the admin password.

You can provide local admin password at this stage. The drawback is that this information will be in plain text in unattend.xml, the answer file for image deployment, in a shared folder (the deployment share). If you don't want the risk of leaking out local admin password, choose not, like I do here. If you choose not, your new machine will have Administrator account enabled with NO PASSWORD SET after the deployment. You will need to remember to set its password for each machine afterwards. However, MDT is powerful enough to let you run command line or powershell scripts during deployment. You can use custom tasks to do various things, e.g. disable the administrator account. I will share this in a later article.

Click through to finish.

Now we have a deployment share and a basic task sequence. Further configuration is required to make things work. See next a few pages.

previous<<   Back to Index   >>next

Windows 7 Deployment - Part02: Create Bootable WinPE USB Drive For Image Capture

previous<<  Back to Index   >>next

Make the USB pen drive bootable:

• Stick your USB drive in.
• Run CMD prompt as Administrator.
• Run 'diskpart'.
• Run the following commands:

list disk

select disk 2  <-- (on my system, disk 2 is the usb drive. You need select the right one in your case.)

clean

create partition primary

select partition 1
active

format fs=fat32 label=image quick

exit

A sreenshot is shown below. My disk 0 is local hard drive, disk 1 is a USB hard drive. Disk 2, you can tell from the size, is my USB flash drive.

Now the USB drive is bootable. Done! Note that you only need to do it once for this USB drive to be bootable, until someone makes it non-bootable.



The next step is to copy the relevant files in to make it a WinPE disk.

Go to Start -> Microsoft Windows AIK, and run the command prompt as Administrator.

In the command prompt, if you run a dir command, you will see something like this:

amd64, ia64, x86 are the WinPE files for different hardware architecture. I run 64bit machines, so I need amd64. Google 'amd64 vs ia64' to see what you require.

You can use manual copy command to copy the relevant files into your USB drive. Or you can use 'copype.cmd' provided by AIK to do the job.

The syntax of copype.cmd is like:

  copype.cmd <arch> <destination>

Let's use c:\winpe folder for our purpose. Type in the following command. Note that I use amd64.

    copype.cmd amd64 c:\winpe

(If this is not the 1st time you run it, and c:\winpe exists already, you can delete the folder from the windows explorer.)

Running the script creates the following directory structure and copies all the necessary files for that architecture. For example,
c:\winpe\iso  <-- holds the 'prodution' content that will go in the bootable USB flash drive or CD.
c:\winpe\mount  <-- mount point.



Add further customization

Add ImageX.exe. ImageX.exe is platform dependent, hence you need to add the right one for your system, i.e. x64 or x32? Go the the right location, e.g. in our case of 64bit system, C:\Program Files\Windows AIK\Tools\amd64, run

  copy imagex.exe c:\winpe\iso

NB: at this stage, you can also inject network driver into the WinPE image, so that when you boot your machine up using the USB drive, you can use 'net use z: \\<server>\<folder>' etc to access network files. See the end of this article for steps.

Now everything you need is gathered together.

In your windows explorer, go to c:\winpe\ISO folder, select all the files, and copy them to your USB pen drive.

You can now boot your reference machine from this usb drive to WinPE mode, and use ImageX to capture the image into a WIM file.


Alternatively, if you are short of USB pen drives and wish to use a CD/DVD (to me it seems a waste of plastic), you can do so by running the following command:

  oscdimg -n -bc:\winpe\etfsboot.com c:\winpe\ISO c:\winpe\winpe.iso

This will produce a ISO file, c:\winpe\winpe.iso. You can now burn it to a CD.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Optional: Inject device drivers to offline image using DISM

Our winpe image as created above resides in c:\winpe.
Put your device drivers in, say,  C:\drivers\latitude.

To inject driver to the winpe image:

  Dism /image:C:\winpe\mount /Add-Driver /driver:C:\drivers\latitude /recurse

To double check what drivers have been injected:

  Dism /image:C:\winpe\mount /get-drivers

Commit (save) the changes:

  Dism /Unmount-Wim /MountDir:C:\winpe\mount /Commit

Since the files in c:\winpe\ISO is the 'production' content that will go into a bootable USB flash drive / bootable CD/DVD, we now need to update the 'produtction' image to the new image we just modified:

  copy c:\winpe\winpe.wim c:\winpe\iso\sources\boot.wim

You can now copy the files in c:\winpe\ISO to your bootable USB pen drive, say, E:\. You can also do it in command line:

  xcopy C:\winpe\iso\* /e E:\

(It seems a lot of steps. But you only need to do it once, and re-use the USB drive over and over again)

previous<<  Back to Index   >>next

Windows 7 Deployment - Part01 : Prepare the reference image with sysprep and ImageX

<<   Back to Index   >>next

Installation: Install Windows 7 on a reference machine. You should endeavour to build your reference Windows 7 in virtual environment. This guarantees your image will run any machine down the road.

Audi mode: the general practice is that all the customisation should be done under audit mode. Once you have installed Windows 7 on a reference machine, go to C:\system32\sysprep, start sysprep.exe. In System Clean Action, select Enter Audit Mode. Shutdown Options, select Reboot. Click OK.


Customization: After the reboot, click through (and enter the info where needed) the pages until you are back in Windows 7 desktop screen. Install the must-have software your organization requires, change the settings as desired, run sysrep again. This time, do NOT use Audit Mode. Use OOBE mode instead. Shutdown the machine afterwards.

Image capture - step 1: you can use MDT 2012 to capture the image. For me, ImageX is simple enough to use. Stick in your bootable WinPE USB pen drive which includes ImageX.exe, get ready to capture. If you want to know how to create a bootable WinPE USB drive, see Create Bootable WinPE USB Drive For Image Capture.

Image capture - step 2: Boot the reference machine from the bootable WinPE USB drive. You will get to X: drive straight away. If you run the dir command, you will realise this is the WinPE drive.

The syntax for image capture is something like:

  imagex /capture c: g:\image.wim "Windows7 Ent x64"

Note: the drive letters vary from case to case, especially when you are not imaging a VM. For instance, in one case, the image to capture is in c: drive, in another case, d: drive. In one case, I wasted quite a bit of time troubleshooting when I just started learning imagex, because I captured the wrong drive.

To summarize: in this case, c: is the drive I need to capture; I stick in another USB drive to save the image.wim file, and it happens to be assigned as g: , so I tuped in g:\image.wim; "Windows7 Ent x64" is the name. To find out which drive is which, just switch to each drive, c:, d:, e:, f:, and so on, and dir to see what's in there.

If you prefer to use network share to store your WIM file, you can use net use to map, say, z: drive to your network share, and save the image.wim to z:. Bear in mind that if you want to do so, you need to include (inject) the network driver in your bootable USB pen drive, as detailed in  Create Bootable WinPE USB Drive For Image Capture.

I tend to use USB drives to save my WIM image. The reason: you will need to inject network driver to the WinPE pen drive to be able to map the network share; this makes your USB WinPE drive hardware dependent. I have a few USB dirves to spare, hence I just save the image.wim file in a spare USB drive, and copy it somewhere else later on (less typing! I am lazy).

When the capture job is done, shut the reference machine down. You can use the following command to do the job. Or you can shut it down by brute force.


  wpeutil shutdown

ImageX also offers more advanced options such as /compress . Check the reference for details. I tried it before, but I tend to keep things simple and leave it out, because the WIM file is pretty small anyway.


Comment: The size of the WIM file is usually a few GB. In my case, just over 3 GB. You can deploy this standard image to your client Windows 7 machines, and MDT Task Sequence can include a step to inject device drivers to target different machine models. Many softwares can be included in the MDT task sequence to auto-install s/w packages to the client machines. Alternatively, you can leave some s/w installation to Active Directory group policy.

You can now see the advantage of Windows deployment using WIM file and MDT - it is versatile and customizable along the line. You can just have 1 reference WIM image, and create multiple Deployment Shares using MDT to accommodate different device drivers for different PC hardwares, or even 1 Deployment Share for multiple PC models, if you can manage all the configuration. It does not require much storage space. The hind side is that MDT can take time to master without someone takes you by hand and show a working case to you: you will be going through many tutorials, blogs and youtube videos to collect information, and each method used by all these system admins varies here and there. It takes time to try each setting/configuration out. Yes, I've gone through all that myself. In the following articles, I will share my knowledge and experience of MDT2012 with you. Hopefully it will make things easier for you.

Now. This is a lovely afternoon. Warm sunshine with a bit of breeze. I shall be going into the garden and see how my flowers are doing...

               <<   Back to Index   >>next