ISATAP can be very useful if you need to manage out from a machine with an IPv4 address to a machine with an IPv6 address. This is commonly used where DirectAccess has been deployed as all DA clients will be using IPv6. Being able to RDP to them or use the SCCM Remote Control feature from a machine inside your network is very helpful for the IT support staff – it’s as if the user was just working from their desk like usual!
One time I was configuring an ISATAP interface on a server and I got the follow error in the event log:
Unable to update the IP address on ISATAP.yourdomain.com. Update type: 1. Error Code: 0x490
I scratched my head over this for quite a while – setting up an ISATAP interface should be easy! After a while I remembered that there was a history of disabling the IPv6 components on servers via GPO. It turns out that even though the GPO had been removed, the setting to disable IPv6 had been tattooed on the servers it had once been applied to.
To check this I had a look in the following location in the registry:
The value was set to
0xFFFFFFFF (it may instead be set to
0xFF). This disables enough of the IPv6 components to prevent an ISATAP interface from being able to be created.
Simply delete the DisabledComponents key and restart the server. So long as everything else is set up correctly you will have your ISATAP interface when you next log in.
Getting your operating system deployment one step closer to being zero touch is always a good goal, so with that in mind here is how to automatically enable BitLocker during OSD using a PIN that you define in a variable at the beginning of the Task Sequence.
The first thing to do is add the
OSDBitlockerPIN variable to the collection you advertise your OSD Task Sequences too. This is very likely the All Unknown Computers collection. Right click on it and select Properties. Navigate to the Collection Variable tab and click New. The name is
OSDBitlockerPIN and you should untick “Do not display this value in the Configuration Manager console”.
Next up open your Task Sequence and add the Enable BitLocker step. This can be placed anywhere after the Setup Windows and ConfigMgr step.1 Make sure Current operating system drive is selected and then select TPM and PIN. You can then enter anything into this field as it will be overwritten by what you enter into the
OSDBitlockerPIN variable when you start the Task Sequence.
Finally, go ahead boot your client into the WinPE environment. Select your Task Sequence and click next and you will be presented with the Edit Task Sequence Variables step. You may already use the
OSDComputerName variable in which case you will already be familiar with this! Double click on
OSDBitlockerPIN and enter the PIN you wish to use for this machine.
Click Next and the Task Sequence will run and complete. BitLocker will be enabled and the PIN will be set. Now you don’t have to configure BitLocker after the operating system has been deployed!
1I would add the Enable BitLocker step at the very end of your Task Sequence, otherwise you will have to enter the PIN each time the machine reboots after applications or updates are installed. You could suspend BitLocker before each reboot, but why go to the extra effort.
While trying to update one particular server using SCCM 2012 R2 I discovered that it was not updating, with the following error was appearing in WindowsUpdate.log and UpdatesHandler.log:
Scan failed with error = 0x80244021
In my case this issue was occurring because a proxy server was configured but no exception was in place for the WSUS / SCCM server. This meant that the server was trying to access the WSUS server through the proxy! To see what my proxy settings were I opened an elevated CMD prompt and entered the following command:
netsh winhttp show proxy
The following information was returned:
Proxy Server(s): ProxyServer.local
Bypass List :
As you can see, the bypass list is empty. In order to create an exception for the WSUS server, enter the following command:
netsh winhttp set proxy ProxyServer.local "https://WSUSServer.local" 1, 2
This sets the proxy and sets the WSUS server as an exception. Re-running
netsh winhttp show proxy will now show you the following output:
Proxy Server(s): ProxyServer.local
Bypass List : https://WSUSServer.local
As you can see the WSUS server is now part of the bypass list, meaning that attempts to access this website will not go through the proxy.
Restart the WindowsUpdate service and re-run the Windows Update scan. You should no longer see scan error 0x80244021.
1Whether you use HTTP or HTTPS for your WSUS server depends on your WSUS or SCCM configuration.
2If you need to add multiple exceptions enter the first one, followed by a comma, followed by the next one and so on.