I recently got an Apple Time Capsule to replace my old linksys cable router. It’s a great little unit but one thing was causing me an issue with my home setup and I couldn’t initially get it to play nice with my home network.

Due to the nature of my work I have quite a few machines on my home network. These are using for testing out various bits of Microsoft software such as System Center Configuration Manager and MDT. This involves a number of virtual and physical hosts, a full Microsoft Active Directory, DHCP and DNS setup. I also have a number of virtual client machines which are constantly rebuilt for testing. The way I have it setup is that the Microsoft DHCP server is responsible for allocating IP addresses and it causes the clients to use the Microsoft DNS (along with the Dynamic DNS registrations) along with some other specific DHCP scope options. The Microsoft DNS is setup to forward external DNS requests to the router. This ensures that all the Microsoft clients can correctly register themselves in the Microsoft DNS but can still access the internet directly. All my other non-Microsoft devices (laptop, iPad, TV, etc.) can work normally as well.

For this setup to work, all I do is to turn off the DHCP server on the router so that the Microsoft DHCP server can take over. This is where the problems started because you don’t have that option in the interface for the Router Mode. You only get these options:

• DHCP and NAT – This is the default mode and it runs a DHCP server and lets clients access the internet.
• DHCP Only – This runs a DHCP server but doesn’t function as a router.
• Off (Bridge Mode) – This is just used for acting as a wifi extender.

None of these modes work for me. What I actually need is an AirPort Extreme “NAT Only” router mode that doesn’t exist.

If you have more than one DHCP server on a LAN then both will try and hand out IP addresses to clients, but the client will register with the first server that responds. My solution was to configure the Time Capsule so that it was running in the DHCP and NAT mode so that it could be correctly used as an internet gateway, but I would configure it so that it had no free IP addresses to hand out. This would mean that any clients would only be able to successfully request an IP address from my Microsoft DHCP server.

My solution is:

• Set the Router Mode to “DHCP and NAT”.
• Create the smallest possible DHCP range (2 IP addresses in the AirPort software).
• Create “dummy” reservations for the DHCP range so that the addresses can’t actually be used.

Here is how I configured it. I’ll be using the IP range of 192.168.0.x 

Open the AirPort utility and go to the Network tab. Set the Router Mode to “DHCP and NAT” as shown in the screenshot above.

Click the Network Options… button and setup the DHCP for the 192.168 network and the range will be from 253 to 254 then click Save.

This will mean that the AirPort Extreme will have the address 192.168.0.1 and it will hand out the 192.168.0.253 and 192.168.0.254 addresses to clients. But we don’t want to the hand out any addresses! We get around this be creating a couple of dummy reservations. From the Network tab and in the DHCP Reservations section, click the + symbol.

Now enter a new reservation with the name DummyReservation1 and a MAC address of 00:00:00:00:00:00 and click Save.

Add a second reservation with the name DummyReservation2 and a MAC address of 00:00:00:00:00:01 and click Save. (Note: the two reservations must have different MAC addresses or they will vanish when you save the configuration).

The DHCP Reservation list should now look like this:

Finally click Update to store and activate the new configuration. Remember that your other DHCP server is now in charge of handing out IP addresses in that range – in this case that is 192.168.0.2 to 192.168.0.252.

The post Configuring an AirPort Extreme for NAT Only Mode appeared first on AutoIt Consulting.

Current environment is CentOS 5.8 (upgraded many times from earlier versions of 5.x) running on a dedicated server (Quad core, 8GB RAM, mirrored disks).

CentOS packages aren’t upgraded throughout the lifetime of a major release (all 5.x versions) aside from security fixes. This means that the OS is very stable and great for hosting but it can require some custom packages of newer software to cater for the websites that I want to run. Significant packages include:

• Apache 2.2.22 (Jason Litka Repo)
• MySQL 5.1.48 (Jason Litka Repo)
• PHP 5.2.17 (Jason Litka Repo)
• Subversion 1.7 (self build)
• Python 2.4

As you can see, the only “standard” CentOS package is Python 2.4 as many of the CentOS internals rely on it and upgrading it can cause major problems.

The main web applications we use are:

Tuesday 13th November, 2012

Attempted to upgrade MediaWiki to version 1.20 and found that it now has a minimum requirement of  PHP 5.3. I found that CentOS had unusually released a special set of PHP 5.3 RPMs so I installed those. PHP immediately stopped working and this was traced to my APC (PHP accelerator) extension which needs to be compiled against the correct version of PHP. I reinstalled APC using “pecl” and everything worked again. I was pretty pleased that PHP 5.3 was running as there are more and more applications (particularly WordPress extensions) which require 5.3 that I could now use.

I looked to upgrade Trac to v1.0 which has always been fairly straightforward, but found that it now had Python 2.5 as a minimum requirement. I could attempt to build a custom version of Python just for use in Trac, but I decided that as my hosting provider could supply a CentOS 6 image that I would use the opportunity to rebuild the server entirely (with so many upgrades and custom packages it would be nice to get back to a fresh install).

Unfortunately, the ISP imaging process will wipe the disk entirely, making the upgrade “fun”…

Wednesday 14th November, 2012

I spent a couple of hours double checking my backup processes. These are performed daily using a combination of:

• Plesk Backup Manager – Backs up hosting settings, email, DNS and MySQL databases.
• Custom shell scripts – Backs up anything not handled by Plesk – there’s a lot of tweaks to config files that happen over the years that I want to preserve. I also manually backup the MySQL databases in addition to Plesk as I’m a little paranoid…

The custom shell scripts create a rolling 30 day set of backups locally on the server. They also store the backups on a special FTP server provided by the ISP for off-server backups. Once a month I take a copy of  the latest backup to my home machine. This is not a quick operation as the backup files are 4 GB…zipped!

After checking the backup scripts I notice that the local FTP upload has not been working correctly due to an ISP infrastructure change. I also find that the newer version of Plesk that I’m using no longer backs up some of the customisations to web hosting config files that I’d made.

Time to triple check the scripts!

Thursday 15th November, 2012

During the rebuild the site is likely to be offline for a number of hours. At some point (after Plesk initially restores the hosting and database settings) the websites will likely be “up” but “broken” as I install the various software packages that the web applications depend on. I don’t want my Google rankings to be hit during this time and I want to minimise the problems that users get trying to use a half-installed site. This Google Webmaster post recommends using the 503 HTTP result code to indicate that the site is temporarily down so that search results don’t get mangled. I added the following code to my hosting configuration and will be enabling it just before I start the full site backup and restore.

ErrorDocument 503 "Our website is temporarily closed for maintenance. Please check back later."
RewriteEngine On
# TO ALLOW YOURSELF TO VISIT THE SITE, CHANGE 111 222 333 444 TO YOUR IP ADDRESS.
RewriteCond %{REMOTE_ADDR} !^111\.222\.333\.444$
RewriteRule .* - [R=503,L]

This will allow me to access the web sites normally with my IP address, but anyone else will get the 503 message.

Friday 16th November, 2012

I took the sites offline with the 503  message above and started the backup to the ISP local FTP site. I also took a copy to my home machine where I manually extracted the files to make sure that they looked OK. I started the ISP server image process for their CentOS 6.3 image. A nice feature of the 1&1 hosting package I use is that you can connect to your server via a SSH Serial console – this means that even if the server is completely broken and not on the network you can still interact with it. And when doing a server rebuild this helps to reassure myself that something is actually happening.

The imaging process took about an hour, and then it took another hour to download and extract the backup from FTP. Unlike my backup scripts I’d don’t have scripts to automate the restore process – usually I’m rebuilding to a different platform so it would be tricky to automate properly. However I have notes for every piece of software I need which documents how I set it up previously. I also keep a master list of Yum packages in a script so that I can reinstall every Yum package quickly.

A summary of the restore procedure is:

• Run “Yum Update” to ensure that all components are current
• Reinstall Yum packages from my master list
• Run some custom scripts that recreate the users and permissions I need
• Extract backup files from FTP
• Use the Plesk Backup Manager to restore the website files, basic hosting settings, DNS, email and MySQL databases

At this point the main website functionality was restored and the website and forums could be brought online again which I did by removing my 503 message. The site was usable again for the majority of users and I could restore the rest of the site services over the next few days (Subversion, Trac, etc).

The post Website Server Rebuild Diary appeared first on AutoIt Consulting.

• Creating a custom XML file for migrating customer-specific application settings
• Creating a custom XML file for migrating user data as per the customer requirements
• Creating a custom config.xml file to fine tune built-in migration settings

These instructions are for ConfigMgr 2012 but they are pretty much identical for ConfigMgr 2007 as well. A state capture and restore is usually done as part of a Operating System Deployment Task Sequence. For the purposes of this walkthrough I’ll be showing a cut down Task Sequence that just captures user state using a ConfigMgr State Migration Point (SMP). Note: I’m also assuming that any custom XML files and a custom config.xml file are copied into the same folder as the USMT package.  (For example. USMT\amd64\config.xml and USMT\amd64\CustomData.xml). To see how to create your USMT package see this previous post.

The Task Sequence actions we are interested in are:

• Request State Store – This allows the client to access the ConfigMgr State Migration Point
• Set OSDMigrateAdditionalCaptureOptions – This sets a special Task Sequence variable to allow the use of custom USMT command line options
• Capture User State – This performs the state capture
• Release State Store – This releases access to the ConfigMgr State Migration point

When creating an OSD Task Sequence with User State Migration the Task Sequence automatically includes Request State Store, Capture User State and Release State Store. The Set OSDMigrateAdditionalCaptureOptions is our custom action. The default actions can also be manually created from the User State Task Sequence menu.

Let’s look at the Set OSDMigrateAdditionalCaptureOptions step first. This is just a standard action that sets a Task Sequence variable.

The OSDMigrateAdditionalCaptureOptions variable allows us to add our own parameters to the scanstate.exe command line when executed. In this example we set the value to the following:

/uel:30 /ue:* /config:"%_SMSTSMDataPath%\Packages\%_OSDMigrateUsmtPackageID%\%PROCESSOR_ARCHITECTURE%\Config.xml"

Those options in more detail:

• /uel:30 /ue:* – Standard scanstate.exe options that mean we exclude local accounts, and we exclude accounts not used in the last 30 days
• /config:”…” – This allows us to specify our custom config.xml file. Unfortunately we must use a full path to the USMT package and config.xml file. The various variables in this allow use to specify the location of the USMT package after it is downloaded to the client so that we can provide a full path to the config.xml file.
• %_SMSTSMDataPath% – Resolves to the root location of the cached package on the client, e.g. C:\_SMSTaskSequence
• %_OSDMigrateUsmtPackageID% – Resolves to the package ID, e.g. AUT00002
• %PROCESSOR_ARCHITECTURE% – Resolves to the build architecture, e.g. amd64 or x86

The next step is to use the Capture User State task to specify which migration XML files we want to use. We use the Customize how user profiles are captured option and add the filenames of the migration XML files. In this example I want to use a couple of default USMT files (MigApp.xml and MigUser.xml) along with my own custom XML file (CustomData.xml). These files must be stored in the USMT\amd64 or USMT\x86 folder of the USMT package as appropriate.

And that’s it. This example USMT capture will now use our custom command line switches, custom config.xml, and custom migration files along with the ConfigMgr State Migration Point. I’d also recommend using the verbose logging option in the Capture User State action. This means that a log is produced on the client at C:\Windows\CCM\Logs\scanstate.log. This is very handy when trying to get this procedure to work as one of the first log entries is a summary of the command line options that were used.

The procedure for creating custom Restore User State options is similar except the custom Task Sequence variable name is OSDMigrateAdditionalRestoreOptions and the variable used in this would be %_OSDMigrateUsmtRestorePackageID%.

The post Using Custom XML and Config Files with USMT and ConfigMgr appeared first on AutoIt Consulting.

These instructions are for ConfigMgr 2012 but they are pretty much identical for ConfigMgr 2007 as well.

First, get hold of the USMT 4 files. These can be found on the ConfigMgr server in the folder C:\Program Files\Windows AIK\Tools\USMT.

Copy these to your ConfigMgr software library share. In this example we will copy them to \\SERVER\ConfigMgr_SWStore$\OSD\USMT.

Note: In order to properly support migrations to/from Office 2010 you must also download the updated USMT components from this knowledge base article: http://support.microsoft.com/kb/2023591.

Now create a standard ConfigMgr package:

On the program type screen select Do not create a program - the OSD task sequences will handle this for us.

The USMT package is now ready for use in an OSD Task Sequence using the Capture User State and Restore User State actions.

The post Create a USMT Package in ConfigMgr appeared first on AutoIt Consulting.

These instructions are the same for both ConfigMgr 2007 and 2012.

Edit your deployment Task Sequence and select the Partition Disk 0 node. By default there is a single partition, we will create an additional partition so that we end up with two partitions named:

• System Reserved
• OS

Call the first partition System Reserved and configure it with the following options:

• Partition type: Primary, Use a specific size (300 MB)
• Make this a boot partition: Checked
• File system: NTFS, Quick format

For Windows 7 you only need a 100 MB partition for BitLocker, but I prefer to use 300 MB to leave room in case you want to use the Windows Recovery Environment.

Call the second partition OS and configure it with the following options:

• Partition type: Primary, Use a percentage of remaining free space (100%)
• File system: NTFS, Quick format
• Variable: OSPART

The variable OSPART can now be used to correctly identify the partition to be used in the Apply Operating System step of the Task Sequence. Configure as follows:

• Destination: Logical drive letter stored in a variable
• Variable name: OSPART

Now when this Task Sequence runs the disk will be partitioned correctly for future use of BitLocker. Alternatively, you can also just use a single partition and run the BitLocker preparation utility to shrink and partition the drive. This is sometimes useful when using USMT and hard linking to preserve disk contents. Personally, I’m a little paranoid and generally prefer to use USMT to backup to the network and then properly clean and partition the disk as above.

The post Create a Windows 7 BitLocker Partition in ConfigMgr appeared first on AutoIt Consulting.

This article states the supported database configuration for ConfigMgr 2012 – it doesn’t appear to mention collation type but apparently this will be updated in the future: http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig

The supported collation type is: SQL_Latin1_General_CP1_CI_AS

For reference, here are some screenshots on how to set this collation type during the installation of SQL Server 2008 R2.

The post ConfigMgr 2012 SQL Database Collation appeared first on AutoIt Consulting.

As these drivers can be a little difficult to find, this post details the download locations of MDT and ConfigMgr build drivers for Windows 7 that will cater for 99% of the machines that you will ever likely encounter. I’ll try to keep it updated whenever the download locations change (I’ll be using this page as a reference point for myself too!).

Intel® Rapid Storage Technology – Boot Critical Driver

This driver will handle Intel RAID and SATA for the vast majority of Intel desktop and laptop machines. Without this driver Windows will be unable to access the local hard disk.

Download Intel® Rapid Storage Technology Driver (select your required OS version in the dropdown list)

To extract the driver files run:

iata_enu.exe -e -p C:\Intel_RST_Driver

Intel® PROSet Wired Network Drivers – Network Driver

These PROSet drivers will handle Intel wired Ethernet on the majority of desktop and laptop machines.

Download Intel® PROSet Wired Network Drivers (select your required OS version in the dropdown list)

To extract the driver files run:

PROWin.exe /f C:\Intel_PROSet_Driver /s /e

Broadcom NetXtreme Desktop Drivers – Network Driver

If a machine doesn’t use the Intel PROSet drivers then it’s almost certainly going to be the Broadcom NetXtreme variety.

Download Broadcom NetXtreme Network Drivers

Intel® 5, 4, 3, 900 Series Chipsets – System Drivers

These Intel chipset drivers aren’t required for boot or reference images but they handle a lot of the ‘unknown’ devices on Intel-chipset machines. I tend to include these as a generic set of drivers for most machines rather than using the vendor versions that are often outdated.

Download the Intel® 5, 4, 3, 900 Series Chipsets Drivers (select your required OS version in the dropdown list and download the .ZIP version)

Summary

Armed with the latest versions of these drivers you should be able to get your MDT or ConfigMgr build process working on most of the machines in common use saving you hours of hunting around the baffling array of drivers on Intel’s website!

The post MDT and ConfigMgr Build Drivers for Windows 7 appeared first on AutoIt Consulting.

First, on a collection used for OSD deployment select Modify Collection Setttings and goto the Collection Variables tab. Enter the following variables:

• OSDSystemLocale: en-GB
• OSDInputLocale: en-GB
• OSDUserLocale: en-GB
• OSDUILanguage: en-US
• OSDUILanguageFallback: en-US

Note: A common error is trying to use a value of en-GB for the UILanguage - there is no such UI setting, Brits have to make do with American spellings in our Microsoft products… The collection variables should now look like this:

Now create a simple unattend.xml file using the Windows Automated Installation Kit and the Windows System Image Manager tool. You need to:

• Add the component amd64_Microsoft-Windows-International-Core_neutral to the specialize section. (use the x86 component if you are using a 32 bit version of Windows 7)
• Enter the ‘OSD…’ variables we created above in the relevant sections wrapping them with % signs, for example %OSDSystemLocale% for the SystemLocale entry.

When finished it should look something like this:

Save the unattend file in a suitable folder (I’m saving it in \\server\ConfigMgr_SWStore$\OSD\Unattend\Win7SP1x64_Unattend.xml – using the folder structure suggested in this post). I tend to put various unattend.xml files for different uses in the same folder then I create a single package for them all for simplified use – in this example I’ll call it OSD Unattend Files.

The final step is to attach this unattend.xml file to your OSD Task Sequence. Select the Apply Operating System task and enter the package and unattend file name in the Use an unattended or sysprep answer file… boxes:

Now when you use this task sequence the collection variables will be expanded inside the unattend file and voila – per collection regional settings! You can also set these same variables directly on computer objects if you need to specialise for an individual computer.

The post Setting a UK Keyboard in ConfigMgr 2007 OSD appeared first on AutoIt Consulting.

First I create a single share with the following properties:

Then create a folder structure as shown in this image:

The top level folders are split into Apps, OSD and Updates.

The Apps folder:

The OSD folder:

The Updates folder:

Here is a zip file of the entire folder structure you can use as a template: ConfigMgr_SWStore.zip

The post ConfigMgr 2007 OSD Folder Structure appeared first on AutoIt Consulting.

There is a free tool called Package This that can turn selections from the online TechNet library into a compiled help file (.chm) that you can then read and search offline! Yes, it seems to have a few bugs but if you keep the selections small it seems to work very well indeed.

As an example I will demonstrate downloading the Operating System Deployment section of the Config Mgr 2007 documentation. Here are the steps to create a .chm from selected content:

1. Download and install HTML Help Workshop (If running Windows Vista and later you will get a message after installation saying that you already have a later version installed – that’s fine, but Package This doesn’t seem to be able to use it until you’ve attempted to install this older version).
2. Download the latest version of PackageThis.exe.
3. Run PackageThis.exe.
4. Select the TechNet Library from the Library menu.
   
5. Find the content you want – you can either choose single pages or get a whole section by using Select This Node and All Children. Note: it’s best to keep the selections small as the program has a few bugs and will sometimes not work correctly. 
   
6. The selected articles will be downloaded – this can take some time depending on the number selected.
   
7. Once all the content has been download select Export to Chm File… from the File menu.
   
8. Enter the filename and title for the .chm file and click .

If all goes well you should now have a .chm file with the selected content that you can access when away from the Internet! As a bonus it’s even searchable.

The post Get Selected Microsoft TechNet Library Content Offline appeared first on AutoIt Consulting.

For sequencing I’ll be using Windows XP SP3 and creating a package that can be used on all later operating systems. I’ve set up the Windows XP machine as per the recommendations in App-V 4.6 SP1 Sequencing Guide – essentially all AV has been turned off, Windows update is off, and the App-V 4.6 SP1 sequencer has been installed. In my case the App-V sequencer machine is a Hyper-V virtual machine so that I can use snapshots to quickly get it back to a clean state.

Onto the recipe:

1. Download the AutoIt full installer from this page.
2. Run the Microsoft Application Virtualization Sequencer.
3. Select Create a New Virtual Application Package.
4. Select Create Package (default).
5. On the Prepare Computer screen check that there are no warnings (Windows Defender is running, etc.) and then click Next.
6. Select Standard Application (default) and click Next.
7. At the Select Installer screen browse to the AutoIt installer (it should be something like ‘autoit-v3.3.6.1-setup.exe’) and then click Next.
8. In the Package Name screen enter the name AutoIt v3 as the package name. Note that this automatically generates the ‘Primary Virtual Application Directory’ of Q:\AutoIt v3. (in App-V 4.6 you no longer have to use 8.3 filenames so this automatically generated name is OK). Click Next.
9. The AutoIt installer will start. Use the defaults for all installation questions except for the installation folder which must be changed to match the Primary Virtual Application Directory of Q:\AutoIt v3.
10. At the end of installation deselect Show release notes and then click Finish.
11. Back in the App-V sequencer, select I am finished installing and then click Next.
12. Select the following tasks to run: AutoIt Window Info, Compile Script to .exe, Run Script, SciTE Script Editor. Then click Run Selected.
13. Close down all the launched applications then back in the App-V Sequencer click Next.
14. Review the Installation Report and then click Next.
15. We need to customize the package a little so select Customize and then click Next.
16. Remove shortcuts as required for your corporate environment and then click Next. I would recommend removing ‘AutoIt v3 Website’ and ‘Check for Updates’.
17. At the Prepare for Streaming page run the same applications as shown in step 12, close them after launch, and then click Next.
18. Select Allow this package to run on any operating system and then click Next. (In theory, you could also create a specific 64-bit package as the AutoIt installer only installs 64-bit components when installed on a 64-bit machine, but the 32-bit version is fine for 99% of cases).
19. Select Save the package now and Compress Package and click Create. Optionally enter the version name in the comments field.
20. Click Close and you’re done!

The post App-V Recipe: AutoIt v3 appeared first on AutoIt Consulting.

There are two main tools that people turn to when troubleshooting Aero:

• Running the ‘Find and fix problems with transparency and other visual effects‘ troubleshooter that attempts to automatically find and fix issues.
• Re-running the Desktop Window Manager (DWM) WinSAT test (either through the standard interface or by running ‘winsat dwm’ from the command line).

In the case of this particular issue both of these methods will not solve the problem and simply report that ‘DWM not running‘ or ‘Desktop Window Manager is disabled‘ and the system will still not enable Aero. The strange thing is you can get Aero by doing the following:

• Right-click the desktop, select Personalize.
• Re-select the standard Windows 7 theme (or any other Aero theme).
• Aero magically starts working again.

Obviously, manually selecting the Windows 7 theme on each machine isn’t going to work when you are deploying more than a couple of machines, but there are two simple solutions.

Solution 1

The easiest solution for an enterprise customer is probably going to be by using Group Policy:

1. Find the path of a theme we want to use – aero.theme is the standard Windows 7 theme and can be found in C:\Windows\Resources\Themes\aero.theme
2. Open the Group Policy console (gpmc or local group policy as required).
3. Find the policy User Configuration \ Administrative Templates \ Personalization \ Load a specific theme
4. Enter the path of the theme, we will use an environment variable so that it works on all machines: %windir%\Resources\Themes\aero.theme
5. Save the policy and apply it to the relevant Organizational Units (OUs).

Note: This only changes the theme for a user’s first-time logon which makes it quite a neat solution.

Solution 2

The second solution can be used when deploying Windows 7 using an unattend.xml answer file. To make the required changes:

1. Open the unattend.xml answer file in the Windows System Image Manager which is installed with the Windows Automated Installation Kit (WAIK).
2. Add the component amd64_Microsoft-Windows-Shell-Setup_neutral to the Specialize pass (use the x86 version if not using Windows 7 64-bit).
3. Find the Themes \ ThemeName entry.
4. Add the Aero theme name you wish to use – use just the main part of the filename (see the Windows Theme folder screenshot above). For the standard Windows 7 theme the value is ‘aero‘.
5. Save the unattend.xml file and deploy!

The post Windows 7 Aero Theme Not Enabled After Deployment appeared first on AutoIt Consulting.

The descriptions given in this article are fairly high-level for a number of reasons. I wanted it to be readable for the general IT admin, and hard documentation on the exact workings of this stuff is virtually non-existent so it contains quite a lot of educated guesses. The epic Windows Internals book discusses both the logical prefetching and ReadyBoot mechanics in a lot of detail, but many of the services and registry keys mentioned in that book reference Windows Vista and they no longer apply to Windows 7 (although the functionality is still there and has been improved, it’s just less obvious which services and keys now control the process).

Logical Prefetcher

Various analysis of boot tracing have shown that one of the main factors that slows the boot process down are disk seek times. As the various boot files, dlls, and drivers are loaded there are lots of page faults and disk seek requests as different parts of files and directories are accessed. Windows 7 keeps track of what files were accessed and the location of these files on the disk and this tracing continues for up to 120 seconds after boot, or 30 seconds after the user’s shell (explorer.exe) starts, whichever comes first. These traces are stored in C:\Windows\PreFetch:

Logical Prefetcher Trace Folder

Each trace contains a list of the files and directories accessed when a given application starts (or during boot) and this information is used to give the prefetcher a chance to prefetch all the data required in one go, so that the loading of the application can be optimized.

In addition, any files referenced by these boot applications (DLLs, SYS files, etc) are also tracked in C:\Windows\PreFetch\Layout.ini. Every few days, when the system is idle, defrag.exe is called with a command-line parameter that causes all these referenced files to be moved to a contiguous area of the disk. This means that the prefetching of these files is much more efficient and further improves the boot time. You can manually invoke defrag to optimize boot files by running the following command (Windows 7 only, the parameters are different on Windows Vista):

defrag.exe c: /b

(This will only work after the machine has been booted around 6 times, otherwise you will get an error about the lack of boot optimization files)

Note: When fully optimized this defrag command should complete quickly (a couple of minutes or so) as the boot files will already be in a contiguous area of the disk. However, I’ve seen machines many months old that have taken up to an hour for this defrag command to complete which leads me to believe that the automatic idle processing may not actually work correctly in all situations. Therefore, it’s a good idea to run the command manually.

You can see the last time the automatic boot defrag occurred by checking the value of the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher\LastDiskLayoutTimeString. Unfortunately, this value doesn’t appear to be changed when you run the defrag command manually.

ReadyBoot

According to the Windows Internals book, the logical prefetching described above is used when the system has less than 512MB of memory. If the system has 700MB or more then an in-RAM cache is used to further optimize the boot process (it’s not clear from the book whether or not this ReadyBoot cache completely replaces the logical prefetching approach or just builds on it, my assumption is that both work together). After each boot the system generates a boot caching plan for the next boot using file trace information from up to the five previous boots which contains details of which files were accessed and where on the disk they were located. These traces are stored as .fx files in the C:\Windows\PreFetch\ReadyBoot folder.

ReadyBoot Trace Folder

Services

Under Windows 7, the service that handles ReadyBoot optimization is part of the Superfetch service.

Under Windows Vista, ReadyBoot optimization was part of the ReadyBoost service (ironically, when Windows Vista came out the advice on “tweaking” sites was to disable ReadyBoost if they weren’t going to use USB/ReadyBoost to improve performance – errrm, no…)

There are some semi-undocumented registry keys that control the prefetch and superfetch operations, but in all but the most exeptional cases they should not be touched. They are only documented on the Windows 7 embedded sites for Disabling Superfetch and Disabling Prefetch. The default value for boot these keys is 3 which enables both boot and appliction prefetching.

An Example

So, does this prefetching and boot optimizing actually work? The following table shows the boot times on an ancient Toshiba Tecra M5 (circa 2004) through its first boot, the subsequent five boots and finally after the disk is defragged with the boot optimization switch. The machine is using a vanilla version of Windows 7 Ultimate SP1 x86 – no applications are installed. The boot time is measured using the bootDoneViaPostBoot metric generated from the Windows Performance Toolkit (WPT) (The boot logging process is detailed in this previous blog post)

You can see the massive improvement that occurs in the first few boots and then some smaller but significant gains in the later boots and the final defrag optimization. This example used a vanilla machine with very few drivers installed and no additional applications. The more drivers and software installed the more files must be accessed during boot which means these optimizations are likely to have an even more pronounced effect.

As this optimization is automatic it’s not something that most people will need to worry about. But if you are building machine that you would like to boot as quickly as possible from the moment it is deployed (appliance PCs, laptops, etc.) then it may be worthwhile adding a “boot training” and defrag task to your deployment processes.

The post Windows 7 Self Optimizing Boot Process appeared first on AutoIt Consulting.

Preparation

First, you need to install the WPT on the machine you wish to examine.

Sysinternals Autologon

Secondly, we will be tracing the boot process all the way until the user has logged in and the desktop is shown. If we rely on quickly and manually logging in we introduce inconsistencies to any timings we do. The simplest solution is to use the Sysinternals Autologon tool available from the Sysinternals site and to configure it with the local or domain user we will be using for testing.

Performing the Boot Trace

1. Logon to the machine as an administrative user.
2. Use AutoLogon to setup the test user that will be used to automatically login during the trace. The test user need not be an administrator, but if not you will need to respond to any UAC prompts during the process to allow the tools to elevate to complete the trace.
3. Create a local folder, for example C:\PerfTrace, to store the boot trace.
4. Open an Administrator command prompt and change to the trace folder created above (cd C:\PerfTrace).
5. Run the command:

xbootmgr -trace boot

6. The machine will automatically shutdown, reboot and finally login.
7. A “Delaying for boot trace” message will appear and the system will pause for 120 seconds to capture post-logon events.
8. The tool will now elevate and a UAC consent box or prompt for credentials will appear.
9. The trace will be completed and the trace files will be written into C:\PerfTrace\boot_BASE+CSWITCH_1.etl.

Analysing the Boot Trace

You can look at the boot trace in two main ways. The first way is to export the trace into XML which allows you to see the main timing points and the second is using the xperfview GUI.

Analysing using the XML Summary

To export the XML summary run the following command with the trace captured in the previous section:

xperf -i boot_BASE+CSWITCH_1.etl -o summary.xml -a boot

The resulting XML file can be opened in Internet Explorer (or your favourite XML editor). In order to expand and contract the individual nodes in IE you will need to allow active content by clicking on the yellow information warning box at the top of the screen.  Contract all nodes apart from the those in the “timing” node to show the following view:

The two most immediately useful metrics are:

• bootDoneViaExplorer – Duration of the boot (in milliseconds) until the start of Explorer.exe
• bootDoneViaPostBoot – Length of the boot transition including PostBoot. This metric represents the total time of a boot transition.

In this example, bootDoneViaPostBoot would seem to indicate that the total boot time was 50 seconds (50094 millseconds). However, a boot trace waits for 10 seconds (postBootRequiredIdleTime) at the end of a boot until the system reaches an idle state. Therefore to get the actual total boot time we must subtract 10 seconds, in this example the adjusted boot time was 40 seconds.

Analysing using the xperfview GUI

To use a GUI to examine the boot trace open the trace in xperfview with the following command:

xperfview boot_BASE+CSWITCH_1.etl

There are many different views to look at in the xperfview GUI, but for this post we will concentrate on the main boot and logon processes (similar to the XML summary). Scroll down to the Winlogon section:

There are many different checkpoints here but some useful ones are:

• GP Client – This checkpoint occurs at a number of different points. Before the user logs in (Computer Group Policy) and after logon (User Group Policy). It is very useful to identify any GPO related problems.
• CreateSession Notification – This checkpoint occurs when the user enters their credentials and starts the logon process.
• Profiles – This checkpoint occurs when the user’s profile is being loaded.
• StartShell Notification – This is the last checkpoint when the shell is ready to load and explorer.exe is about to be launched. It corresponds to the WinlogonInit endTime entry from the XML summary.

Summary

This post showed how to perform boot logging using WPT at the most basic level. This can be a very complicated process and far too much to cover in a single post, future articles will go into more detail in individual areas.

The post Windows Performance Toolkit: Simple Boot Logging appeared first on AutoIt Consulting.

Unfortunately, the WPT is included as part of the Windows 7 SDK and cannot be downloaded separately, and the SDK download is a whopping 2.5GB! However, by following these steps it is possible to download only the minimal files required to gain access to the WPT MSI files. These MSI files can then be internally redistributed for easy installation of WPT. Here are the steps:

1. Download the Microsoft Windows SDK for Windows 7 and .NET Framework 4 (it’s a bootstrap setup and is only around 500KB).
2. Run the file winsdk_web.exe.
3. Accept all defaults until the Installation Options screen is reached.
4. Deselect all components except Redistributable Packages \ Windows Performance Toolkit. (Depending on the client, you may not have the option to deselect the .NET 4 tools)
   

   Windows 7 SDK Options for WPT

5. Complete the installation.
6. Browse to C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Windows Performance Toolkit. Copy the wpt_x64.msi and wpt_x86.msi files.
   

   WPT Redist Files

These wpt_*.msi files can now be used to install the WPT on any client machine and should be kept in a safe place so that you don’t need to download the SDK each time.

The post Windows Performance Toolkit Installation appeared first on AutoIt Consulting.

This blog will share tips, tricks and scripts related to Microsoft Windows deployment and related technologies.

Until we start blogging in earnest, here are some links to some articles done by myself (Jonathan Bennett) for my former employer Microsoft MCS on the excellent Deployment Guys blog. Send us an email if you have any requests for the sort of content you would like to see.

Previous Posts on the Deployment Guys

Windows 7 VDI Optimization

GImageX

Dealing With Duplicate User Profile Links in Windows Vista

Working with crashdumps – debugger 101

The post Welcome to the AutoIt Consulting Blog! appeared first on AutoIt Consulting.