There can of course be many reasons for broken ConfigMgr content distribution – lack of space, physical security on disks and many, many others. This is one possibility though – can the site server actually reach the DP though WMI? If not, then this will undoubtedly cause problems.
This happened to my infrastructure, I suspect, through a patch deployment. See here for more information. Anyway, to test if this is an issue, run up a session of WBEMTEST and connect to the DP in question from your site server via:
Assuming you’re getting ‘Access Denied’ (typically with an 80004005 error) this may well be the fix you’re looking for. You will also see the following in the SYSTEM eventlog of the DP:
The server-side authentication level policy does not allow the user XXX from address XXX to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.
You’ll likely see the following in Distribution Manager status messages:
The business of adding a front end for a PXE-driven SCCM OS build is generally a pretty important consideration if you want to specify some basic information prior to deployment. It’s also something that I’ve felt has never been properly addressed by the SCCM development team. To be fair you could argue it’s not their job to do this but with more functionality being adding to every single aspect of SCCM in every new release, it does feel like something that probably should be looked at in the future.
For now, there are plenty of examples of great front ends on the internet – look up ‘Pretty Good FrontEnd’ by Johan Arwidmark or ‘Pretty Good Front End Clone’ by Maik Koster. These two have been around donkey’s years. One of my favourites is Nicolaj Andersen’s very neat ConfigMgr Front End which offers a whole world of features. Additional infrastructure is necessary to accommodate this however, in the form of web services.
So why create another? Well I’m certainly not pretending to set the world alight with some kind of ingenious new approach but I always felt there was just a little too much fiddling about with most of the solutions I saw elsewhere. What I wanted was something I could ideally just drop straight into my WinPE image which would just work. There are certainly features I could add (and may indeed do so if enough people ask) such as ability to remove certain sections, eg, domain, OS, etc. However in an effort to keep things simple I have left this for now.
The Front End
This is a typical illustration of what it looks like in my lab. Most aspects are configurable via a small ini file (yes I know it’s a bit 90’s but let’s face it, it’s a damn sight easier to use than an xml file for this kind of thing). The ini file below is configurable for the OUs in your environment, the domain (or domains) and even colour and font size. One area I went a little off the beaten track is the ability to select different images you want to use in your task sequence. This is great in my lab as I often want to test stuff out on different OS’s and will routinely add a new image when necessary to my tried and trusted task sequence. As such I’ll detail this a little more.
If you want to use the same task sequence but have different images available in that sequence, you can enter them in the ini file. Just be sure to enter the appropriate option/filter in appropriate task sequence step. For example, in the image above we have a number of different OS’s which relate to separate images. Under the INSTALL section of your task sequence you might have one or more separate steps to Install Windows 10, Install Server 2016, etc. On each of these steps, click Options and add a Task Sequence Variable condition, eg:
TS VARIABLE: OSDImageEquals <Windows 10 1803>
It is important that the text in the OS box above equals the OSDImage value of your condition.
Of course, you can just add a description in the Config.ini file instead and have one image step in your task sequence with no condition set and all will be well. I suspect this is what most people will want. The option to do it this way is just there if you want it.
Typical Config.ini settings below. This file must always exist in the exact same folder as the NewFrontEnd.exe executable.
:: [ORG_UNIT] - Enter all OUs you want displayed in format OU=Dept, OU=Org, DC=domain, DC=suffix one after the other.
:: [DOMAIN] - In most cases, this is more for show but can be used to build a workgroup machine too if WORKGROUP is specified underneath the primary domain.
:: [OS] - If your task sequence can build more than one image, add it here, eg Windows 10 1607 LTSB. Then add a task sequence variable condition called OSDIMAGE and equal it to the image name in your TS.
:: LOGO, recommended max size is approx W:120, H:120 for a font size of 8-10
:: BACKGROUND, Enter standard OS colour names, eg Red, DarkRed, Marroon, MidnightBlue, etc
:: FONTSIZE, recommend, 8-10 but it will go bigger. Seems to jump in 2s, eg, 8,10,12, etc. This has a bearing on the size of the form.
:: FONTCOLOR (American spelling, sorry) see BACKGROUND, above.
:: SMSTSPREFERREDADVERTID, If specified, enter the Deployment ID of the task sequence you want to run. This will override any other advertised task sequence either 'available' or 'required' and the wizard won't show.
:: HIRESDISPLAY, If HIRESDISPLAY=True the size of the form is increased so it doesn't get 'scrunched up' on the display. This has been tested against a Surface Pro 4.
:: NOTE - [ORG_UNIT], [DOMAIN] and [OS] should all have at least one value (ideally) so the interface has something to show. Settings under [MISC] can be removed or ignored by adding a semicolon before the setting.
Windows 10 1803
Windows 10 1607
Windows Server 2016
Windows 2012 R2
Windows 10 1607 LTSB
Windows Server 2008
So how do you get this working in WinPE?
Create a share somewhere and drop NewFrontEnd.exe, Config.ini and your company logo png into it (and/or possibly RunFEUI.vbs – see end of post)
In SCCM go to your chosen boot image, right-click | properties | Optional Components. Select Microsoft .NET (WinPE-NetFx). This is a C# application so it needs this option available in your boot image binaries.
Select the Customisation tab. Under Prestart Command Settings enter “X:\sms\PKG\SMS10000\NewFrontEnd.exe”
Select Include files for the prestart command
Select the share you created above with the files in for the source directory.
If you want to, add a background, click OK and you’re done. After the update distribution points wizard has completed, double check the Last Update information in the bottom section of the SCCM console to ensure the time matches the time you ran the wizard and everything has updated as it should. This is important as it hasn’t usually finished updating just because the wizard progress bar has completed.
For The Adventurous.
One of the neat things about using the above method is that there is no ugly command prompt in the background as it brings up the front end interface. However the downside of this is that all the files are inside your WinPE image so if you want to update them you have to go through the above process once again which is both time consuming and laborious. One solution though is to simply point to a script that will map a drive to a share that exists elsewhere on your network and execute the files from there instead. This facilitates updating the files on the fly.
In the zip file included below, there is a file called RunFEUI.vbs. Simply open it and edit it to fit your environment (ie edit line 4 with the appropriate drive mapping and account).
Had a tag-team of problems with Office 365 Client updates and this one reared its ugly head just a I managed to successfully get the O365 updates syncing successfully.
Under Software Library|Office 365 Client Management|Office 365 Updates none of the client updates were checking in as ‘required’. Given that the O365 client on 5000-odd machines was at version 16.0.8201.2207 (v1705) this seemed odd to say the least. Everything was set correctly in SCCM for O365 Client Deployment so the summary screen should theoretically be showing that the whole estate needed at least every version beyond this.
After some considerable digging I discovered that for updates to work in SCCM, the CDNBaseUrl and the UpdateChannel settings in the registry MUST BE IDENTICAL. In my case, whoever had packaged the application had a bogus entry in the UpdateChannel setting that made no sense. I copied the CDNBaseURL setting (something along the lines of http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60) into the UpdateChannel setting, restarted the Microsoft Office Click-To-Run service and ran an update scan and update deployment policy refresh from the SCCM control panel applet. Immediately O365 client updates showed up as required. This can be checked under the following ConfigMgr report:
Compliance 8 – Computers in a specific compliance state for an update (secondary)
I then set up a GPO to push this URL out to the estate and watched the count increase.
All http://officecdn.microsoft.com is whitelisted and available, definitely no issue there.
All other updates seem to come down fine.
There are no ADR rules at all in place.
Running a full sync produces the error below:
My client downloads updates through a proxy server and naturally the correct details for the proxy were in place on the Site System Settings under Site System Roles. Also the checkbox for Use a proxy server when synchronizing software updates was checked under the Proxy And Account Settings tab under the Software Update Point Properties role.
Despite the fact that ADRs were NOT created or used in any way, it transpired that the checkbox Use a proxy server when downloading content by using automatic deployment rules also had to be checked. Once this was selected, O365 updates started syncing.
Headaches of an SCCM Admin. But no other symptoms yet.