Author: Alex

Web API Notification Abuse

After years of little development World Wide Web Consortium (W3C) awoke from its slumber with the first public preview release of the all new HTML5 specification. This started to allowed web developers to do much more with webpages without requiring plugins. It wasn’t until 2014 when it was finalised, and they didn’t stop there with newer versions being developed to this day. At the same time ECMAscript (Javascript) has been hugely updated and revised. Developers have the tools to make every much more powerful and interactive websites than ever before.

One of the new features is Web API Notifications. The concept is good; however, the API is being abused at high speed. Web API notifications allow the browser to prompt you whenever there is an update from a website, whether you are on the site or not. This is handy for email, IMs and news notifications. Marketers have started to take advantage of this as well, using it to push product information offers to visitors. Marketing is annoying; however, the bad guys are using it as well to lure users to clicking and downloading malware onto their computers.

Before a site can send notifications, the user will be presented with he following box asking for permission:

Web API Notification Permission Request in Google Chrome

The problem is many users don’t fully understand what it is or think it is something to do with cookies, and then click Allow. There is little if any explanation as to what it is asking. The bottom line is it needs to be implemented better, with the user’s safety and possibly sanity in mind. Over the past couple of weeks, I’ve taken a huge number of tickets related to popups of all kinds from API notifications.

In the meantime, this is how to disable them in Chrome and Firefox:

Google Chrome

  1. Go to “Settings”
  2. Under “Privacy and security” click on “Site settings”
  3. Under “Permissions” click on “Notifications”
  4. Under “Allow” you will see all the sites with permission. Click on the 3 dots next to each site you want to stop and click on “Block”
  5. To disable all notifications, switch the toggle for “Ask before sending” to put all in blocked mode.

Mozilla Firefox

  1. Go to “Options”
  2. Under “Privacy & Security” and find “Permissions”
  3. Next to “Notifications” click on “Settings”
  4. Click on “Remove All Websites”
  5. Check the box at the bottom called “Block new requests asking to allow notifications”
  6. Click “Save Changes”

Performing Active Directory Tombstone Reanimation

With the exception of dynamic objects, when an object is deleted in Active Directory it is not immediately removed from the database. Instead a “tombstone” of the object containing a subset if attributes, including the SID, is placed in a hidden container called “Deleted Objects”. This allows for the possibility of restoring the user account, although this method should only be used if an authoritative restore and recycle bin cannot be used.

The length of time tombstones are kept depends on the operating system which created the forest to begin with. For Windows Server 2000 and 2003 it is 60 days. Whereas for Windows Server 2003 SP1 and above were set to 180 days. By default every 12 hours the garbage collector service comes along on each DC to permanently remove tombstones which have exceeded this duration. These values can be altered in ADSI Edit.

Tombstones can be “reanimated” using LDP, which is able to access the Deleted Objects container. Be aware that this will only restore a disabled account which with missing attributes and can produce unexpected results. Once restored a new password needs to be set and the account enabled. The process of reanimation requires making the following attribute amendments:

distinguishedNameReplaceDN to the destination OU of the user e.g. CN=John Smith,OU=Accounts,DC=example,DC=com

Follow these steps to recover a deleted user account using LDP.exe:

  1. Run “ldp.exe” on a DC, click “Connection”, “Connect…”, for the server specify the server name to connect to and click “OK”.
  2. Click “Connection” and choose “Bind…”, use the default option to connect as the current user and click “OK”.
  3. Click “Options”, “Controls” and then under “Load Predefined” choose “Return deleted objects” and click “OK”.
  4. Click “View”, “Tree” and set the “BaseDN” to “CN=Deleted Objects,DC=Your Domain” and click “OK”
  5. Expand the tree view for deleted objects and look for the object to reanimate.
  6. Right click on the object and choose “Modify”.
  7. In the “Attribute” textbox type “is Deleted”, select the “Delete” radio button and then click “Enter”.
  8. Clear the Attribute text box and enter “distinguishedName”, in the “Values” textbox enter the new DN for the user, e.g. CN=John Smith,OU=Accounts,DC=example,DC=com if the user was John Smith from accounts, click Enter and then “Run”.
  9. In AD Users and Computers you can find the account in a disabled state ready to have the password reset and enabled again.

Issues with Adobe Reader 2019.008.20071

Recently Adobe released a routine update for their flagship PDF reader Adobe Acrobat Reader DC. On the surface the biggest change users should have noticed was some fancy new icons, however a couple of nasty little bugs have also made an appearance.

The first bug that was reported to me was images emended within the documents were no longer printing and the second was the Save As option was greyed out. Thankfully there are a couple of work around which can be used whilst Adobe bring out their next update to resolve these issues.

How to resolve the images not printing

  1. Open a PDF to print
  2. Go to File and then Print…
  3. Click on Advanced and then check Print As Image
  4. Click OK and then Print

How to resolve the missing save functionality

Currently the best action to take to resolve this issue is to reinstall Adobe Reader, some may wish to take this opportunity to revert back to a previous version.

Windows Deployment Services Error 7024 + 268 (3238134273)

I recieved error 7024 (3238134273) when trying to start the WDS service on a server without DHCP running on it.

The description for Event ID 7024 from source Service Control Manager cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
Windows Deployment Services Server
The locale specific resource for the desired message is not present

System Event Log

An error occurred while refreshing Image Cache. The Windows Deployment Services server will not process incoming client requests.
Error Information: 0xC1020201

Application Event Log

After taking a look online all I could find were posts about the error being caused by a port conflict with both WDS and DHCP trying to use UDP port 67. As this server did host DHCP this was clearly not the cause in this case.

I tried removing the latest install image I had added and the service started normally again.

Setting up and Configuring WDS and Windows Images

Windows Deployment Services (WDS) is a Windows Server role which allows administrators to configure and deploy Windows images over the network. In order for WDS to work the client computers must have a PXE bootable network card installed. Also DHCP must be enabled on the network so that clients can acquire a valid IP address. The DHCP server may need to have options 66 and 67 configured.

  • Option 60 needs to be set to “PXEClient” if WDS is installed on the same server as DHCP or when using PXE with UEFI clients
  • Option 66 points to the FQDN (Fully Qualified Domain Name) or IP of the PXE server (in the case WDS) e.g. “”
  • Option 67 contains the boot file name on the boot server e.g. “boot\x64\” for BIOS and “boot\x64\wdsmgfw.efi” for UEFI

DNS is also required to resolve the FQDN of the boot server specified in option 66.

For Active Directory integrated WDS servers, the WDS server will need to be a domain controller or member of the desired domain.

WDS uses TFTP (Trivial File Transfer Protocol) to transfer files to PXE Clients, the download phase can get quite intensive and can fail if sufficient resources are not available. Ensure the “Remote Installation” folder is on a separate drive to the OS.

WDS is not cluster-aware, however fault tolerance can be achieved using multiple servers on the same network.

1.1.1WDS networking considerations

Both DHCP and WDS listen on UDP port 67. When the PXE client boots it uses the DHCP DORA (Discover, Offer, Request and Acknowledgement) process to acquire an IP address. As this process uses broadcasts, DHCP only works on the same subnet on which it is configured unless a DHCP agent is installed on a router on the subnet of the client.

Understanding this can help to determine how WDS should be configured in a particular environment.

WDS has a few scenarios where problems can occur if not configured correctly: network with WDS and DHCP on one server

In this scenario both services will be trying to bind to UDP port 67 on the same server. In order to get around this problem WDS needs to be configured to listen on a different port and set DHCP option 60 to “PXEClient”.

By default if WDS is configured after DHCP, the setup will do this for you without the need for any manual intervention.

To manually configure WDS to work on a server which also runs DHCP:

  1. Open Server Manager, go to Tools and choose Windows Deployment Services.
  2. In the left navigation pane, expand Servers, right click on the WDS server and click Properties.
  3. Select the DHCP tab and check the Do not listen on DHCP ports checkbox.
  4. If the servers runs Microsoft DHCP then also check Configure DHCP options to indicate that this is also a PXE server, otherwise you will need to leave it unchecked and manually set option 60 to “PXEClient” on the third-party DHCP software.
  5. Click OK to apply the settings. is located on a different server to DHCP

In this instance DHCP option 60 isn’t needed unless you are using UEFI, however for WDS to work options 66 and 67 need to be configured.

1.1.2Install Windows Deployment Services role

The WDS role relies on the Transport Server feature. The Transport Server feature can be installed on its own and used to build custom PXE deployments. For more information about how this can be utilised see this Technet example.

WDS can run on the same server as DHCP or on a separate server, however the configuration is slightly different. This guide assumes that DHCP and DNS have already been configured using Windows server on your network. the role

As of Windows Server 2012 R2, WDS is not yet supported on Core installations. Also to perform the installation you must be a member of the Local Administrators group.

Using Server Manager
  1. Open Server Manager on the server you want to install the role on, go to Manage and click Add Roles and Features
  2. Click Next three times, check Windows Deployment Services, click Add Features and then click Next four times.
  3. Click Install to start the installation and click Close to exit the wizard.
Using Windows PowerShell
  1. Open Windows PowerShell
  2. Issue the following command:

Install-WindowsFeature WDS -IncludeManagementTools WDS

To initialise an AD integrated WDS server you need to be a member of the Domain Admins and Local Administrators group. For a standalone install just the Local Administrators group.

Configuring using the GUI
  1. In Server Manager click on Tools and then Windows Deployment Services to open the WDS management console.
  2. In the left pane, expand Servers and right click on the WDS server and select Configure Server.
  3. Click Next, choose if this will be Active Directory integrated or standalone configuration and click Next.
  4. Click Browse to choose the location to store the images and boot files and click Next. Note that this should be located on a separate drive to the operating system for performance and must be formatted with NTFS.
  5. If this server is already or will be a DHCP server, both check boxes should be checked so that the two roles don’t interfere (see section and click Next.
  6. Choose which clients to respond to and click Next. Normally during the configuration stage of WDS Do not respond to any client computers is checked so not to interfere with the production network. The responding option is then later changed in properties.
  7. Wait for the wizard to complete and click Finish.
Configuring using WDSUtil.exe

This WDSUtil appears to only initialise if the WDS server is domain joined.

  1. Run Command Prompt as an Administrator
  2. Run the following command:

WdsUtil /initialize-server /reminst:”C:\RemoteInstall

You should change the /reminst path to the location where the remote installation files and images will be stored on the server.

This command will initialise the WDS server with defaults and that means that until told to do so, it will not respond to any PXE Clients.

1.1.3Configure and manage boot

So that WDS is able to deploy and installation image (i.e the operating system image) to the client computer, it needs to load to Windows PE (Preinstallation Environment). To do this once the PXE client has downloaded the initial boot software for BIOS or UEFI, the software will connect to the WDS server and using TFTP, download a boot image. The boot image contains a version of Windows PE which is loaded into RAM.

WDS doesn’t contain a copy of Windows PE by default, instead you can load a number of different versions into WDS and choose which one to boot. It is recommended that they should be sourced from Windows installation media and is included with Windows Vista/2008 and onwards. Windows PE is located in the “sources” folder of the media in a file called boot.wim.

Older versions of Windows PE may not allow for all of the features to be used in news versions of WDS. For example x86 UEFI booting requires Windows PE4.0 or above shipped with Windows Server 2012. boot images using the GUI

  1. Insert a Windows Vista or onwards installation media – Server 2012 R2 is recommended
  2. Open Server Manager, go to Tools and click Windows Deployment Services.
  3. In the left pane expand Servers, expand your WDS server, right click on Boot Images and choose Add Boot Image…
  4. Browse to the media, open the sources folder and open boot.wim.
  5. Click Next, and on the next screen it is often advisable to provide a more meaningful Image Name and Image Description.
  6. Click Next twice and wait for the boot image to be added.
  7. Click Finish

An image can be removed by right clicking on it and choosing Delete. It is also possible to disable the image if you don’t want to remove it all together. images using PowerShell

New to Windows Server 2012 is PowerShell support for some of WDS.

  1. Open Windows PowerShell
  2. Issue the following command:

Import-WDSBootImage -Path D:\sources\boot.wim -NewImageName “Boot Image Name”

The path should be replaced with the path of the installation media (typically drive D) and optionally a new image name can be set.

To verify the boot image has been imported run in PowerShell:

Get-WDSBootImage images using WDSUtil

  1. Open Command Prompt
  2. Issue the following command replacing the ImageFile parameter with the path to your image:

WDSUtil /add-image /imagetype:boot /imagefile:D:\sources\boot.wim

1.1.4Install and discover images

Install images contain the operating system, complete with any desired patches, applications and custom configuration settings. WDS deploys these images to the client computers.

Install images can be found in the “sources” folder of the Windows installation media for Windows Vista/Server 2008 onwards in a file called “install.wim”. Typically “install.wim” will contain a number of different images with in which can be selected at setup. WDS allows us to import all or just some from this file.

Images can be added from other sources, for instance customised images and captured images. It is also possible to to deploy VHD files as installation images. When deploying VHDs, WDS will copy the VHD to the client computer as a VHD. This is so that VHD deployment can take place, however you will need a client OS with a licence to boot from a VHD such as Windows 8 Enterprise edition.

WDS puts images into separate groups, when adding images you need to specify or create a group to add the image in. an installation image using the GUI

  1. Open the WDS MMC.
  2. Expand Servers, expand the WDS server, right click on Install Images and choose Add Image Group…
  3. Enter a group name and click OK
  4. Right click on the new group and choose Add Install Image…
  5. Click browse and find the installation image to add, click Open and then Next
  6. Select which images to add to the group and click Next (optionally uncheck Use the default name and description for each of the selected images if you want to change them)
  7. If you chose to rename, follow the steps to change them, click Next and wait for the image to be added. an installation image using PowerShell

  1. Open Windows PowerShell
  2. Run the following command replacing the appropriate parameters to match your scenario:

Import-WDSInstallationImage -Path “D:\sources\install.wim” -ImageGroup “Desktop Images” -ImageName “Windows 10 Enterprise 2016 LTSB Evaluation”

The “ImageName” parameter is optional and is used to choose which images to import when the WIM file has multiple images within it. You can use the following command to list the images held within a WIM file:

Get-WindowsImage -ImagePath “D:\sources\install.wim” an installation image using WDSUtil

  1. Open Command Prompt
  2. Run the following command replacing the appropriate parameters to match your scenario:

WDSUtil /Add-Image /ImageFile:D:\sources\install.wim /ImageType:Install /ImageGroup:”Desktop Images” /SingleImage:”Windows 10 Enterprise 2016 LTSB Evaluation”

The “SingleImage” switch is optional and performs the same function as the “ImageName” parameter as the PowerShell commandlet equivalent.

Not all NICs (Network Interface Cards) support PXE and therefore cannot PXE boot to contact a WDS server. In some instances these computers may need to acquire an image from a WDS server. To allow these computers to discover a WDS server a boot up, an alternative boot device such as an optical or USB device can have a special boot image call a discover image on them. This is a modified Windows PE image, which when booted will find the WDS server and allow the setup to deploy images located a deployment server.

Discover images are created by copying and adapting a boot image in WDS, consequently before attempting to create a discover image, first make sure there is a boot image loaded into WDS. a discover image using the GUI

  1. Open the WDS MMC and navigate to the boot images folder.
  2. Right click on a boot image and select Create Discover Image…
  3. Enter a Name, Description, choose a location to save the discover image to and optionally specify the WDS server to contact.
  4. Click Next and wait for the image to be created a discover image using WDSUtil

  1. Open Command Prompt
  2. Run the following command replacing the appropriate parameters to match your scenario:

WDSUtil /New-DiscoverImage /Image:”Windows 7 x64 Boot” /Architecture:x64 /DestinationImage /FilePath:C:\discover.wim

The “Image” switch indicates the image of the boot image to use to create the discover image from. a discover image to bootable media

For this exercise ensure you are logged in as a local administrator.

  1. Download and Install the Windows Assessment and Deployment Kit for Windows 8
  2. Run Deployment and Imaging Tools Environment from Start
  3. Run the following commands:
  4. CopyPE amd64 C:\WinPE
  5. Copy /y C:\Discover.wim C:\WinPE\media\sources\boot.wim
  6. Oscdimg -n -b”C:\WinPE\Fwfiles\” C:\WinPE\Media C:\Discover.iso

1.1.5Update images with patches and hotfixes

Images can be serviced offline using a program called DISM (Deployment Imaging Servicing and Management). DISM is a command line tool accessible with Command Prompt and PowerShell. DISM can apply Windows updates from CAB and MSU files, which can be downloaded from the Windows Update Catalogue.

DISM can be pointed at a folder of patches to apply or a specific patch. The following example points to a specific update, to update using a folder set the package path to the folder instead.

To service an image it must be mounted to folder, changes can then be made then when it is unmounted the changes can be committed. patches using DISM Command Prompt

Before continuing use the following command to determine which images are in the WIM file so that you know which one to select and service:

DISM /Get-WimInfo:C:\Install.wim

  1. Open Command Prompt and run the following commands:
  2. MKDIR C:\mount
  3. DISM /Mount-WIM /WIMFile:C:\install.wim /Index:2 /MountDIR:C:\mount
  4. DISM /Image:C:\Mount /Add-Package /PackagePath:C:\Updates\windows8.1-kb4052978-x64.msu
  5. DISM /Unmount-WIM /MountDIR:C:\mount /Commit patches using DISM PowerShell Commandlets

Before continuing use the following commandlet to determine which images are in the WIM file so that you know which one to select and service:

Get-WindowsImage -ImagePath C:\install.wim

  1. Open Windows PowerShell and run the following commands:
  2. Mount-WindowsImage -ImagePath C:\install.wim -Index 2 -Path C:\mount
  3. Add-WindowsPackage -Path C:\mount -PackagePath C:\Updates\windows8.1-kb4052978-x64.msu
  4. Dismount-WindowsImage -Path C:\mount -Save

1.1.6Adding and deploying drivers

Drivers can be applied to images, both boot and install as well as to WDS for images to query and install as required. drivers to images

Divers can be added and removed from images using DISM, using a similar process to managing patches. You should note that system drivers cannot be removed. DISM will only accept drivers in their basic form (inf style drivers), that is the inf file and some associated files. DISM can install either one driver at a time or it can load a folder of drivers using the “Recurse” switch.

To modify the drivers in an image file it must first be mounted, the driver changes then made and the changes saved on dismount of the image. The mounting and dismounting commands are the same as those used for modifying any offline image, see the patching example for details.

To get a list of the current drivers the following commands can be used:

Using Windows PowerShell

Get-WindowsDriver -Path C:\ImageMountPath

Using DISM with Command Prompt

DISM /Image:C:\ImageMountPath /Get-Driver

Drivers can be added by referencing the INF file or the folder containing the INF files. The “recurse” switch can be added to search the folders within the specified directory. The “ForceUnsigned” switch can be used to force unsigned drivers to be added.

Adding a driver using Windows PowerShell

Install a specific driver:

Add-WindowsDriver -Path C:\ImageMountPath -Driver C:\drivers\mydriver\driver.inf

Install add driver in specified folder:

Add-WindowsDriver -Path C:\ImageMountPath -Driver C:\drivers\mydriver

Install all drivers in a set of folders:

Add-WindowsDriver -Path C:\ImageMountPath -Driver C:\drivers\ -Recurse

Adding a driver using DISM with Command Prompt

Install a specific driver:

DISM /Image:C:\ImageMountPath /Add-Driver:C:\drivers\mydriver\driver.inf

Install add driver in specified folder:

DISM /Image:C:\ImageMountPath /Add-Driver:C:\drivers\mydriver

Install all drivers in a set of folders:

DISM /Image:C:\ImageMountPath /Add-Driver:C:\drivers\ /Recurse

Although the drivers initially provided from Microsoft on an image cannot be removed, it is possible to remove any additional drivers when they are no longer required. To do this it is best to list the drivers and find the oem*.inf reference for the driver e.g. oem1.inf. This reference is required to specify the driver to remove.

Removing a driver using Windows PowerShell

Remove-WindowsDriver -Path C:\ImageMountPath -Driver oem1.inf

Removing a driver using DISM with Command Prompt

Removing a single driver:

DISM /Image:C:\ImageMountPath /Remove-Driver /Driver:oem1.inf

Removing multiple drivers:

DISM /Image:C:\ImageMountPath /Remove-Driver /Driver:oem1.inf /Driver:oem2.inf drivers to WDS, configure driver groups and packages

WDS can store reservoirs of drivers in driver groups, these groups can have filters applied to them to target specific computer groups. If no filters are set, any computer can check the group for drivers. By default WDS creates a “DriverGroup1” driver group.

Driver groups can be disabled if required so that they aren’t applied to any hardware without having to delete them and enabled again later.

Adding a driver group:

Currently there isn’t a PowerShell command to create driver groups, therefore they must be created using the MMC or WDSUTUL.

Creating a driver group using the WDS MMC

  1. Open the WDS MMC, navigate and expand the WDS server
  2. Right-click on Drivers and select Add Driver Group…
  3. Type in the group name and click Next
  4. You can then set some hardware filters for the group by clicking Add…
    1. Choose a filter type, operator type, enter a value, click Add and then OK
  5. Click Next and then Add if you want to specify some image filters
    1. Choose a filter type, operator type, enter a value, click Add and then OK
  6. Click Next and choose if you want any hardware which matches the criteria to install all of the drivers in the group or just those that match its hardware
  7. Click Next and Finish

Creating a driver group using WDSUTIL

WDSUTIL /Add-DriverGroup /DriverGroup:NewGroupName /Enabled:Yes

You can also apply filters and applicability settings in this command with the “Filter” and “Applicability” switches.

Delete a driver group using WDSUTIL

WDSUTIL /Remove-DriverGroup /DriverGroup:DriverGroupName

Add a driver to WDS using the MMC

  1. Open the WDS MMC
  2. Expand the WDS server which drivers will be added, right-click on Drivers and select Add Driver Package…
  3. Browse to and select the driver to add and click Next
  4. Wait for the drivers to populate and check the ones to add and click Next twice
  5. Wait for the driver to be imported and click Next
  6. Choose to add the driver to an existing group, create a new group or don’t assign at this time and click Next and Finish

Adding a driver to WDS using Windows PowerShell

Import-WindowsDriverPackage -Path “Driver Path” -Architecture X64 -DisplayName “Driver Display Name” -GroupName “DriverGroup1”

The minimum requirement:

Import-WindowsDriverPackage -Path “Driver Path”

Adding a driver to WDS using WDSUTIL

WDSUTIL /Add-DriverPackage /InfFile:”Path to driver file” /Name:”Driver Display Name” /DriverGroup:”Group Name”

The minimum requirement:

WDSUTIL /Add-DriverPackage /InfFile:”Path to driver file”

Once a driver has been added to WDS it can be referenced using its unique name or id.

Adding an existing driver to a group using the WDS MMC

From All Packages:

  1. Go to the “All Packages” folder and right click on the driver you want to assign/remove from a group.
  2. Select Add or Remove from Groups and use the arrow buttons to choose which groups the driver should apply to.

From the driver group:

  1. Right click on the driver group to add the driver to and select Add Driver Packages to this Group.
  2. Add any driver filters to narrow the search and click Search for Packages.
  3. Select the packages to assign and click Add.

Adding an existing driver to a group using Windows PowerShell

Referencing driver name:

Add-WdsDriverPackage -Name “DriverName” -DriverGroupName “Driver Group Name”

Referencing driver id:

Add-WdsDriverPackage -id driver-id -DriverGroup “Driver Group Name”

Adding an existing driver to a group using WDSUTIL

Referencing driver name:

WDSUTL /Add-DriverGroupPackage /DriverGroup:“Driver Group Name” /DriverPackage:”Driver Name”

Referencing driver id:

WDSUTL /Add-DriverGroupPackage /DriverGroup:“Driver Group Name” /PackageID:driver-id

Removing a driver using the WDS MMC

  1. Open the drive group and select the driver to remove from the group.
  2. Right-click on the driver and choose Remove from this group to just remove from the group or Delete to remove it entirely.

Drivers can be removed on the command line either by referencing their name or ID. The following examples for the name only, however the syntax for ID is similar to that of adding to a group.

Removing a driver using Windows PowerShell

Remove driver from a group:

Remove-WdsDriverPackage -Name “Driver Name” -GroupName “Driver Group Name”

Remove driver entirely:

Remove-WdsDriverPackage -Name “Driver Name” -RemoveFiles

Removing a driver using WDSUTIL

Remove driver from a group:

WDSUTIL /Remove-DriverGroupPackage /DriverPackage:”Driver Name”

Remove driver entirely:

WDSUTIL /Remove-DriverPackage /DriverGroup:”Driver Group Name” /DriverPackage:”Driver Name” drivers to boot images using WDS

WDS makes adding drivers to boot images easier by allowing administrators to do a “point and click” injecting of drivers. Note that it is not possible to remove drivers using WDS. To remove the driver after, the image would have to be exported, then the driver removed using DISM and added back into WDS.

To do this the driver must first be added to WDS. To add a driver to a boot image using the WDS MMC follow these steps:

  1. Navigate to the boot images folder and right-click on the boot image to add the driver.
  2. Select Add Driver Packages to Image… and click Next.
  3. Modify the filters if required and click Search for Packages.
  4. Choose the driver to add and click Next.
  5. Wait for it to be applied to the image and click Finish.

1.1.7Install features for offline images

Like updates and drivers, features are turned on and off using DISM, either via Windows PowerShell or the DISM in the command prompt. The following sections will explain the commands for each method. As discussed in the previous sections images must be mounted first, before DISM can manipulate them. Windows Features using PowerShell

List features:

Get-WindowsOptionalFeature -Path C:\MountDirectory

Enabling a feature:

Enable-WindowsOptionalFeature -Path C:\MountDirectory -FeatureName NameOfFeature

Disable a feature:

Disable-WindowsOptionalFeature -Path C:\MountDirectory -FeatureName NameOfFeature Windows Features using DISM Command Prompt

List features as a table – table is optional:

DISM /Image:C:\MountDirectory /Get-Features /Format:Table

Enable feature:

DISM /Image:C:\MountDirectory /Enable-WindowsFeature /FeatureName:NameOfFeature

Disable feature:

DISM /Image:C:\MountDirectory /Disable-WindowsFeature /FeatureName:NameOfFeature

1.1.8Further reading

Useful tools for IT Administrators

This is my list of helpful tools for IT professionals. I’ll keep adding to it as I discover and think of more tools.

DNS Diagnosis

Computer Hardware Information

Drive and Disk Utilities

Password Recovery

Network Tools

Computer and Network Security

Vulnerability Checking


Installing HP LaserJet M2727nf Drivers on a PC with USB3.0


Recently I was trying to install the Windows 7 driver for a HP LaserJet M2727nf printer on a PC which has a USB3.0 card installed. The installer kept failing to install, telling me it couldn’t find any compatible USB hardware. Considering that USB3.0 is backward compatible to USB2.0 and the standard HP universal driver installed and worked with no issues, I found this very odd.

HP Driver Installation Failure - USB not detected

HP Driver Installation Failure – USB Not Detected


After looking though all of the installation files in the “setup” folder, I discovered an executable file called “usbready.exe”. This is a program dating back to 1998, which was written by Intel, for use by hardware vendors to determine if PCs had USB support. When ran on a PC with USB3.0 it will come back with this screen:

USBReady.exe not detecting USB support on USB3.0 bus

USBReady.exe not detecting USB support on USB3.0 bus


The solution to this problem is quite simple.

You will need installed on your computer a copy of 7Zip of some other compression tool such as WinRar or WinZip. I recommend 7Zip it is free, light and easy to use.

  1. Download the driver from the HP site.
  2. Go to the folder you downloaded it to. Open the installer in your compression tool and extract the files. 7Zip users can do this by right-clicking on the file, going to “7-Zip” then “Extract files…”
  3. Once extracted, open the folder you extracted the files to and then open the “setup” folder.
  4. Find the file called “usbready.exe” and delete it.
  5. Go back to the main installer folder and run “Setup.exe” to start the installation.

This time the setup should run without any USB problems.


Further Information

Eli the Computer Guy, (2013). Introduction to Windows Server 2012. [online] YouTube. Available at: [Accessed 10 Jun. 2015].

Jscon, (2012). Understanding Features on Demand and role persistence in Windows Server 2012 – The Windows Servicing Guy – Site Home – TechNet Blogs. [online] Available at: [Accessed 10 Jun. 2015].

Microsoft, (2013). Cloud optimize your business with Windows Server 2012 R2. [online] Available at: [Accessed 10 Jun. 2015].

Microsoft, (2014). Migrate from Previous Versions to Windows Server 2012 R2 Essentials or Windows Server Essentials Experience. [online] Available at: [Accessed 10 Jun. 2015].

Microsoft, (2015). Upgrade Options for Windows Server 2012 R2. [online] Available at: [Accessed 10 Jun. 2015].

Zacker, C. (2014). Exam ref 70-410. Redmond, Wash.: Microsoft Press.

1.1.3 Migrating Windows Server Roles

Migration is the recommended method of moving from an older version of Windows Server to Windows Server 2012 R2. This is because most of the troubles and restrictions encountered when performing an in-place upgrade are no longer and issue. It works by taking copies of critical data from the source (old) server to the destination (new) server with a fresh copy of Windows Server 2012 R2 installed.

Following the migration guide provided by Microsoft, administrators can migrate between:

  • Versions – any version of Windows Server 2003 SP2 or higher
  • Platforms – 32 bit to 64 bit platforms
  • Editions – any edition of Windows Server (provided it supports the required features)
  • Physical and virtual instances – from physical to virtual or the other way
  • Installation options – between Server Core and GUI or the other way

Migration is performed on roles and role services, rather than migrating everything in one go. Windows Server Migration Tools are sometimes required to perform migrations for certain roles and can be installed using the Add Roles and Features Wizard or PowerShell using the following command: “Install-WindowsFeature Migration”.

1.1.2 Upgrading Servers

An upgrade installation is the most likely to have problems due to its complexity and therefore it is recommended that where possible, administrators perform clean installations or migrate applications and roles. If an in-place upgrade has to take place make sure the the server is prepared properly and there is a roll-back plan. Upgrade Paths

Upgrades which are not supported

  • from a 32 bit architecture
  • from Itanium architecture
  • from another language
  • from a workstation computer
  • between build types
  • if it is a domain controller
  • from pre-release versions of Windows Server
  • if the installation type will change (e.g. from Server Core to Server GUI)

If the server is running a 64 bit version of Windows Server 2008 R2 or Server 2012, it can be upgraded to the appropriate edition of Windows Server 2012 R2. Table 5 shows the supported in-place upgrade paths for Windows Server 2012 R2.

Current System Windows Server 2012 R2 Edition
Windows Server 2008 R2 Datacenter SP1 Windows Server 2012 R2 Datacenter
Windows Server 2008 R2 Enterprise SP1 Windows Server 2012 R2 Datacenter or Standard
Windows Server 2008 R2 Standard SP1 Windows Server 2012 R2 Datacenter or Standard
Windows Web Server 2008 R2 SP1 Windows Server 2012 R2 Standard
Windows Server 2012 Datacenter Windows Server 2012 R2 Datacenter
Windows Server 2012 Standard Windows Server 2012 R2 Datacenter or Standard

Table 5: Windows Server 2012 R2 Upgrade Paths Upgrade Preparation

Before performing an in-place upgrade follow this check list:

Check Explanation
Hardware compatibility Ensure the server hardware meets the requirements minimum for Windows Server 2012 R2. Also ensure device drivers are supported on the new operating system.
Disk space There needs to be enough disk space to hold the old operating system, the new one and any setup files.
Check software is signed Device drivers and other kernel-mode software must be signed or the upgrade could be aborted or hardware failures. Uninstall any unsigned software before upgrading.
Gather any required storage drivers To provide the setup with access to necessary mass storage for installation, have a copy of the drivers ready on removable media or placed in “/amd64” directory in the setup location.
Check application compatibility Create an inventory of all the software on the system and check the manufacturer to see if it is compatible. If this is not possible, test it on another server running the new version of Windows Server before upgrading. If the software is critical it is advised that the software is tested in the new environment before an upgrade, regardless of what the manufacturer claims.
Check system for faults Make sure the current install of Windows Server along with any third-party applications are running as they should.
Perform a full backup If anything goes wrong there needs to be something to fall back on. At the very least critical data must be backed up. When imaging the system ensure to take a copy of all boot and system partitions too.
Disable any anti-virus applications Anti-virus software can slow down the upgrade processes and possibly cause problems as well. It is best disabled during the upgrade process.
Disconnect UPS devices Disconnect UPS data cables before running the upgrade as setup will attempt to detect connected devices and sometimes UPS devices cause issues.
Purchase a suitable Windows Server 2012 R2 licence key Check the valid upgrade paths to ensure the in-place upgrade is possible.
Roll-back plan Be prepared to roll-back the upgrade if required. Have a cut-off time which allows enough time for the upgrade to be roll-back, before the maintenance window closes. Ensure the roll-back procedures work before proceeding with the upgrade.

Table 6: Windows Server 2012 R2 In-Place Upgrade Check List

During the upgrade process, the server may restart a few times. Whilst the upgrade is still in progress, the boot menu will provide the option to abort the upgrade and revert the changes. Once the upgrade is completed, this option will no longer be available.