BITS throttling causing slow SCCM client install and policy download

SCCM extensively uses Background Intelligent Transfer Service (BITS) to transfer data between a client and the SCCM server. This also affects downloading client policy! One of the first things that SCCM uses BITS for is to download the client to the machine when you initiate a client push. If BITS is heavily throttled you may find the following entries in your ccmsetup.log file (typically found in C:\Windows\ccmsetup):

Starting BITS download for client deployment files.
Download update: Copy job has been queued.
Download update: Copy job has been queued.
Download update: Copy job has been queued.

There may be some entries showing the progress of the client download, however if BITS is throttled this may be proceeding very slowly.

If you want to check whether BITS is being throttled on a particular machine open a command prompt window and type RSoP to perform a Resultant Set of Policy. Once the RSoP window opens navigate to Computer Configuration —> Administrative Template —> Network —> Background Intelligent Transfer Service (BITS) —> Limit the maximum network bandwidth for BITS background transfers and check if it is enabled and what limitations are in place.

In my case it was limited to 10 KBs at all times! Far too slow to get anything done in a reasonable time.

The next thing you can do before you start talking with your fellow sysadmins and the  network team about removing the throttling is to prove that it is the BITS throttling causing the issue. As long as you are a local administrator on one of the clients this can be done quickly by editing one registry key and restarting the Background Intelligent Transfer Service. Open regedit and navigate to HKLM\SOFTWARE\Policies\Microsoft\Windows\BITS and change EnableBitsMaxBandwidth from 1 to 0. Then open services.msc and restart Background Intelligent Transfer Service. This will remove the BITS throttling on that machine until group policy is reapplied and sets EnableBitsMaxBandwidth back to 1. Before that happens however you should have time to re-deploy the SCCM agent or push a new client policy and observe whether or not it happens in a much more timely fashion than it did before.

ISATAP failing with error 0x490

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP6\Parameters\DisabledComponents

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.