Hi all,
On my company we are on the W10 deployment projec, and we are on the testing phase.
We found several clients where the ConfigMgr client stopped downloading files, after some investigation we confirmed some interesting changes that affect how BITs service is managed on this systems.
The first change is that the management of the jobs from cmd is being deprecated, we receive a disclaimer advicing that bitsadmin will stop runningnow we should use Powershell (Expected as there is tendency to use this for all admin tasks on systems since Windows Vista) and, as the BITs jobs on the ConfigMgr client are created with the Network account, make really difficult to stop the jobs if they get stack on the execution.
I tested with the tool Psexec impersonating the System Account, but no way.
c:\temp\PStools>psexec -i -u “nt authority\networkservice” c:\windows\cmd.exe
PsExec v2.11 – Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals – www.sysinternals.com
Error establishing communication with PsExec service on XXXXX:
The system cannot find the file specified.
c:\temp\PStools>psexec -i -u “networkservice” c:\windows\cmd.exe
PsExec v2.11 – Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals – www.sysinternals.com
Password:
PsExec could not start c:\windows\cmd.exe:
The user name or password is incorrect.
During investigation found the next post: (https://www.systemcenterdudes.com/sccm-hardware-inventory-problem-windows-10-1607/) where is commented a new KB to solve this problem with BITs job stack with the ConfigMgr client, so would be enough the installation to solve the issue (On most environment will need testing before implementation, not so easy to deploy).
But the most interesting part on this post is not solution documented about the KB, is the explanation about how to manage BITs on W10, even if the only solution proposed is to enable EFS, something that may not fit the needs on all environments.
Getting deeper found that we may cancel those jobs following the next steps:
-Stop Bits Service
-Delete the files on the folder “C:\ProgramData\Microsoft\Network\Downloader” (qmgr0.dat and qmgr1.dat)
-Restart the machine and this will download the files again.
But as soon as we have a new inventory run on the client will have the BITs error back. So this will be only usable as an emergency process if need to download files on a machine, but not a permanent solution.
Other option is to have a scheduled task ready to run with the Network Account:
- On Powershel import the BITSTransfer module with the command ‘import-module bitstransfer’
- Create the scheduled task to run the script on the security context for NTAUTHORITY\SYSTEM
BitsJobsCleanSCCM.ps1
$b = get-bitstransfer -allusers
Remove-bitstransfer -Bitsjob $b
Is documented that this command may run “get-BitsTransfer -allusers | Remove-BitsTransfer”, but I had no luck on my testing.
I needed to run on my script:
$b = get-bitstransfer -allusers
Remove-bitstransfer -Bitsjob $b.JobId
3. We may check the BITs jobs status with the commandlet ‘Get-BitsTransfer -AllUsers | fl’.
I hope that this information is useful for you.
All commands and script on this post are just examples, before implement on production test extensively to avoid unexpected results, the use of them is under your own responsibility.
configmgryyo 