Create your own Wifi-hotspot Windows 7 / Windows 8

The topic of making your Windows box a wireless AP, and then sharing internet connection with your wireless devices connected, is not something new, but I’ve never seen anyone wrap Powershell around it. Also this script is designed to work on Windows 7, will work under Windows 8, but with windows 8 and Powershell v. 3.0 some parts will be easier to script. There are 3 parts to creating your personal Wifi-Hotspot:

First allow Windows to control the power state of your Wireless Card. You can either do this from the GUI, or if you’re a geek, you might be looking to do this via Powershell, which is what I’ve done.

Second Enable the HostedNetwork feature available in Windows 7. Again, the technical bits of how this works, and what hosted network can do, is available from Microsoft, here. Good part about the hosted network is that is comes with its own DHCP, so Internet Access will pretty much work out of the box.

Finally Enable Internet Connection Sharing (ICS) – as much as I would like to automate this in Powershell, this just isn’t possible in Windows 7 (I’ll dig inside Windows 8, see if it can be done there). To enable ICS,  follow these Instructions from Microsoft.

The Script

To wrap Steps 1 and 2 up I’ve written a Powershell script that will enable what is needed automatically (so you still have to enable ICS by hand, but that’s easy). Click the link to download Enable-Wifi-HotSpot. You must run this script from an elevated powershell console, it won’t fully work unless you do.

Read on to get some learning points on how I did this.

CAUTION: If you just run the script out of the box, please read the instructions it spits out (it has some commands to temporarily disable your Wifi, so if you are on a wifi only connection you will get disconnected)

Learning Points

First step says….


I wanted to tick the “Allow the computer to turn off this device to save power” check box programatically. This tick box corresponds to the following registry key:


<ID> is a device ID given by Windows to the network adapter when it is installed. When the tick box is checked the first bit of the DWORD value of PNPCapabilities is 0. If the tick box is unchecked the first bit becomes 8.


Also this value is not accepted automatically by the OS, after changing it, you have to reboot (so the Internet says)…but I just went with disabling and enabling the WLAN Adapter and it worked for me. I figured if changing the setting works from the Windows GUI with no reboot there was a way around rebooting.

So our first order of business is to find that <ID> parameter that maps each Wifi adapter to the registry keys. I had the script find all possible Wifi adapters on the system:

$WifiAdapters = Get-WmiObject -Namespace root\wmi -Class MSNdis_PhysicalMediumType -Filter `
 "(NdisPhysicalMediumType=1 OR NdisPhysicalMediumType=8 OR NdisPhysicalMediumType=9) AND NOT InstanceName LIKE '%virtual%'"

I also included integer values for NDISSPhysicalMediumType are included at the top of the script. For reference they can be obtained from 2 places:

  • Windows SDK or WDK (more info here).
  • You can cheat a little and run this command on a Windows 8/ Windows 2012
(Get-NetAdapter | Get-Member PhysicalMediaType).Definition

Once  we have the list of all Wifi adapters, we take each adapter and see if its configuration is OK and it is not disabled. I’m using a filter on the ConfigManagerErrorCode property.  The possible values for this property can be found here.

$PhysicalAdapter = Get-WmiObject -Class Win32_NetworkAdapter -Filter "Name='$($WifiAdapter.InstanceName)'" -Property * |`
 ? {$_.ConfigManagerErrorCode -eq 0 -and $_.ConfigManagerErrorCode -ne 22}

The ID parameter we are looking for is stored in “$PhysicalAdapter.DeviceID” but unfortunately it is not stored in the format we need, (in my case DeviceID = 15, and I needed to transform into 0015). I did it with this line:

$AdapterDeviceNumber = $("{0:D4}" -f [int]$($PhysicalAdapter.DeviceID))

From here on, things get a little simpler. once you get the registry key, I just check if the last HEX digit is 0 or 8.

$PnPCapabilitiesValue = (Get-ItemProperty -Path $KeyPath).PnPCapabilities
 #convert decimal string to HEX to compare first bit
 $PNPCapHEX = [convert]::tostring($PnPCapabilitiesValue,16)

I compare the PNPCapHEX value to see what the first digit is,and decide to just do a “disable/enable” of the wifi adapter, or change the value and then “disable/enable”. Disabling the NIC can be done easily once you have the network adapter object.

$PhysicalAdapter.Disable() | out-null
 $PhysicalAdapter.Enable() | out-null

Note that the commands above return no output. If you take out the out-null, you should see return value = 0. If you get “return value = 5” that is an access denied, and it means you didn’t run the script from an elevated prompt.

Now the registry settings are done, all that is left is to build the netsh command to enable the hosted network. What is “of interest, in this section” is how we read out the wifi password ( I wanted the script to be a little secure, and then how we pass the wifi password to the netsh (that involves converting from secure string to plaintext). For this last conversion I used the function described here.

#now that WiFi adapter is configured, let's add our hotspot
$WifiPassSec = Read-host -Prompt "Enter password for your Wifi, must be at least 8 chars long, complex" -AsSecureString
#enable hosted network
$WifiPass = ConvertFrom-SecureToPlain $WifiPassSec
$SetupHN = "netsh wlan set hostednetwork mode=allow ssid=Rivnet-Wifi key=`"$WifiPass`" keyUsage=persistent`nnetsh wlan start hostednetwork"
Invoke-expression $SetupHN
$SetupHN = $null
$WifiPass = $null

So now you should be all set, just connect your devices to the Wifi and enjoy Internet access via your laptop. Finally, you might want to turn off the hosted network at some time. To do this, run this command:

netsh wlan stop hostednetwork

netsh wlan set hostednetwork mode=disallow

Hopefully this will  help someone out there, looking for a scripted way to do this. For me it was quite a learning journey, since I got to dig inside windows’s internals while scripting this.

How to use KMS server across Active Directory Forests

Recently I made a slight career change and also with it came a small challenge. We were given 2 Active Directory Forests, one was actively being used and the other one had very few users, but was going to get much larger very quick. People were also deploying Windows 7, Windows 2008 R2 and Office 2010. All of these products canuse KMS license keys, which basically means you have one Key Management Service Server in your organization to which all Windows and other MS products refer to for validating their license periodically. That server must have a valid Windows License, which gets activated to the Internet, then you just enable that server as a KMS host Server. Enough with the background, you can read more about deploying a KMS server here.

Now back to the problem at hand. Since the 2 organizations to whom the 2 forests belonged to had pretty loose security requirements, we wanted to save us the hassle of creating and managing a second KMS server, and just using the KMS server we had available. KMS is also not so restrictive when it comes to accepting license validation requests.

KMS clients have 2 ways in which they determine where the KMS service is located (i will use as the “main” forest for this example):

  • Specify it manually using a built in windows command line script. For example to specify the server for a machine just run from administrator command prompt this command:
cscript %windir%\system32\slmgr.vbs /skms
  • Windows uses DNS to determine the KMS servers (pretty much like Windows does to determine which servers offer AD Authentication). When KMS host is installed in creates an SRV record in the DNS in This record looks like this:

ServiceName: _vlmcs

Port: 1688 (default)

Host offering the service:

The Final srv record looks like this:

As you can see there is not so much rocket science in the way a KMS host is published in DNS. Also there is no requirement that the computer trying to validate a license against KMS be joined to a domain. All the computer needs does is a srv DNS query to determine where the KMS licensing host is. Based on this information it talks to KMS and validates the licenses.

So to make sure computers in forest, for example, can find KMS in DNS do following:

1. Create a new A Record for the IP address of the KMS server, in DNS, for example

2. Create a new SRV Type record in DNS, with following details

ServiceName: _vlmcs

Port: 1688 (default)

Host offering the service:

The Final srv record looks like this:

You can do all this by using dnscmd (available in Windows7/2008) run this command:

dnscmd <DNSServerName> /RecordAdd <ZoneName> _vlmcs._tcp SRV 0 100 1688 <HOST-Offering-Service>

3. Test from a client computer that the SRV record is available in DNS, by running this on a command prompt:

nslookup -type=srv

You should get an output that points to the DNS record you created in step 1.

4. Test the client computer can validate his license to the KMS host by running this command from an elevated command prompt:

cscript %windir%\system32\slmgr.vbs /ato

cscript %windir%\system32\slmgr.vbs /dli

There should be a line like this:

KMS machine name from DNS:

And that’s it with using KMS from any other forest in your own AD. In short:

1. Add Host record for KMS host

2. Add SRV record for KMS host

3. Attempt activation, verify activation was done using KMS host.

Fix High Hardware Interrupts on HP Probook 6540b

A few days back I discovered an “issue” with new installation of Windows XP on HP Probook 6540b laptops (have read reports on the internet about 6440b behaving the same). What I noticed is that after installing all the drivers from the HP website, computer appeared sluggish, especially disk operations, opening task manager was a 5 second task. The solution to this problem was to obtain the latest disk controller drivers from the Intel Website and then install a specific controller type, instead of letting Windows choose automatically. But first, time for this small disclaimer:

The steps below should be attempted after you have backed up your Windows installation and/or relevant documents, please do not attempt this procedure before doing a backup of your system. Double, triple, quadruple check that the problems I am describing here exactly match your hardware, software and symptoms observed. This procedure can damage your operating system, possibly even the hardware, this post comes with no warranties, it is not supported by HP, Intel or any other vendor as far as I know. Also this post is valid at the time of writing, new fixed drivers may appears by the time you are reading this, making it obsolete.

Symptoms and Conditions

  • Sluggish Disk performance
  • Sluggish computer performance when doing disk based operations
  • BIOS is configured to use IDE mode not AHCI mode for SATA disks (you configured for IDE because AHCI was not working)
  • Device Manager is showing a primary IDE channel device configured for PIO mode only – you cannot select UDMA mode
  • Using SysInternals Process Explorer reveals 25% CPU is Hardware Interrupts when accessing disk continuously (on an i5 cpu that is 1 core…spread over all 4 cores). Interrupts usage goes down when disk is idle.
  • Your storage controllers are detected as:
    • “Intel(R) 5 Series/3400 Series Chipset Family 2 port Serial ATA Storage Controller”
    • “Intel(R) 5 Series/3400 Series Chipset Family 4 port Serial ATA Storage Controller”
  • The Storage Controllers detected above have Hardware ID’s:
    • PCI\VEN_8086&DEV_3B2D
    • PCI\VEN_8086&DEV_3B2E

Trials and Errors

As you can see starting from the High Hardware interrupts up to device being put into PIO mode, it is clear that there is some driver issue somewhere. What you can try and watch it fail:

  • Delete disk controller devices then use scan for hardware changes so windows will reinstall drivers. After reboot you will see the problem still exists.
  • Delete disk controller devices then download latest Intel drivers, automatically choose which driver to install. After reboot you will see no changes, same device will be detected, same drivers installed.
  • Reinstall OS re-add drivers one by one, you will have the same problem.

The solution

You need to manually select a device driver to install from the driver package for Intel’s Rapid Storage Technology (I think the former name for these drivers, in general, was Matrix Storage Manager). The problem is that the drivers that come with Windows can only use PIO Mode, and the driver package from Intel does not contain the Hardware ID’s you found above. The drivers do work, to get them to work you have to either:

  1. Manually install drivers selecting a specific device driver to install
  2. Hack the driver files so they include your device ID’s (“hardcore” option, try #1 before you go there 🙂 )

Option 1 – Do a manual driver install

This works mostly after you installed the operating system. here’s what you need to do exactly:

  • Download the driver package
  • Using Device Manager delete storage controllers from the laptop
  • In Device Manager click “Scan for hardware changes“, the New Hardware Wizard appears
  • Choose don’t search Windows Update
  • Next choose “Install from specific location
  • Next choose “Don’t search I will choose driver to install
  • On the next screen click on “have disk” and point it to the location of the extracted driver files. Click OK to close driver selection. List will be populated with a bunch of devices
  • From the devices list select “Intel(R) 5 Series 6 Port SATA AHCI Controller
  • Click OK and correct drivers should install now. If you are asked to reboot, choose OK
  • After the reboot go into the BIOS, change SATA mode to AHCI. If you keep SATA mode to IDE your XP install will BSOD (the reason is you added SATA drivers to XP, and the controller talks IDE, if left unconfigured)
  • Now you should see that your devices are installed correctly and you have no more hardware interrupts. Also the Disk Controllers section in Device Manager looks different, fewer devices left there.

Option 2 – Hack the Driver files

This option is useful if you want to make a driver package for an unattended installation or just want to have a set of drivers that will work “out of the box”. What we will do in short is add a few lines of code to the files in the driver package, pointing the Hardware ID’s to the Intel(R) 5 Series 6 Port SATA AHCI Controller” we manually installed with Option 1. Here’s how to do it:

  • Extract drivers to a folder, you should have these files inside among some other txt’s:
  • Open iaAHCI.inf file for editing and search at the end of the file for the “strings” section. Look for the string “PCI\VEN_8086&DEV_3B2F&CC_0106.DeviceDesc” which matches to the Intel 5 series 6 port controller . As you can see after the DEV_ follows “3B2F”, pretty similar to our Hardware ID’s:
    • PCI\VEN_8086&DEV_3B2D
    • PCI\VEN_8086&DEV_3B2E
  • Before the DEV_3B2F line create 2 new lines where you duplicate the DEV_3B2F line, BUT you replace 3B2F with the last 4 characters from the other device ID’s (one line will have 3B2D the other 3B2E). The point is to have the Hardware ID’s of your controller point to the correct driver name.
  • Now we have to track any place in the document where “3B2F” appears and add the same text for Hardware ID’s 3B2F and 3B2E. The section you are looking for to add lines are in “[INTEL_HDC.ntx86]“, there is a line containing 3b2f, add 1 line for each Hardware ID.
  • Save iaAHCI.inf and close it
  • Update Disk Controller drivers by pointing Windows hardware wizard to your modifed .inf file

With this inf file Windows should be able to install the driver it needs without you having to select which driver to install from the list. The logic is that now Windows knows where to find the correct drivers, because the Hacked Intel Driver contains the device ID’s Windows is looking for.

Option 2+, unattended installs

This next section is about changing the TXTSETUP.OEM so you can do unattended installations using this hacked INF file. You can follow the Intel guide to injecting drivers for “F6 Install”, but you need to change the TXTSETUP.OEM file that comes with this package. Do following:

  • From the driver package Open TXTSETUP.OEM for editing.
  • In the iaAHCI.inf section look for the “Intel(R) 5 Series 6 Port SATA AHCI Controller”. To the left of that string is the text “iaAHCI_5_1”.
  • Do a search for the string “iaAHCI_5_1” in the document, you should find a section called “[HardwareIds.scsi.iaAHCI_5_1]”.
  • When found copy it and the line after it ( looks like “id = “PCI\VEN_8086&DEV_3B2F&CC_0106″,”iaStor””) 2 times. The 2 copies you can change instead of being 3B2F to 3B2D and 3B2E respectively.
  • In the end you should have 3 “hardwareIDs” sections, 1 with 3B2F, the original and the other 2 Hardware ID’s you need.
  • Save and close TXTSETUP.OEM.
  • Follow Intel’s “F6 install” procedure to deploy Windows XP using these modified files (all the files in the package + modded iaAHCI.inf and TXTSETUP.OEM)
  • You must configure BIOS to use AHCI mode, drives will not work with IDE mode (didn’t for me)

Phew, this was a long and “hard” post. I hope the general idea is clear:

For installing from windows just make sure to select the controller I mentioned (the 6 port device) when doing the complete manual install.

For the hacked inf and OEM files double check and triple check the changes you are making. the point is to add the HW ID’s to the INF file, so it will install the drivers the same way as for the Hardware ID ending with 3B2F.

My best guess is that this mess-up is due to some slightly different versions or ID’s being stamped erroneous onto the controllers when they were shipped. I hope this was helpful, please report back any mistakes you notice.