Exception: System.ArgumentNullException: Value cannot be null. Parameter name: objectID at Microsoft.ConfigurationManager.PhasedDeployment.Application.Deploy(IDatabaseOperation databaseOperation, List`1 phases, String phasedDeploymentID, String objectID) at Microsoft.ConfigurationManager.PhasedDeployment.PODRuleEngine.EvaluatePhasedDeployments(SqlConnection connection)
I was testing a phased deployment the other day and couldn’t get it to work for the life of me. Although the phased deployment appeared under the Phased Deployments tab for the Office 365 application I was targeting, a corresponding deployment didn’t appear for the phase 1 collection under the Deployments tab.
I took a look at the SMS_PhasedDeployments.log on the site server and all I could see was the error message above. I would also see it repeat about every 2 minutes as below.
It kept mentioning there were two phased deployments it was trying to evaluate, but there were no other phased deployments set. There is a well-known bug when a task sequence can get locked and the admin will typically go into the db and remove the offending ID locking the task sequence from the database. Well it turns out this is a similar issue with an equally similar solution.
Go into the ConfigMgr (sorry, Endpoint Manager!) DB and find dbo.PhasedDeployment, right-click the table and click Select Top 1000 rows.
Identify the offending Phased Deployment from the list and copy the PhasedDeploymentID.
Click New Query from the toolbar and type:
DELETE FROM dbo.PhasedDeployment WHERE PhasedDeploymentID='<PhasedDeploymentID>'
I would be inclined to delete and recreate your original phased deployment (from the console!) to be sure of a clean deployment but technically you be good from here on.
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.
Difficult to pick a snappy title for this so suggestions welcome!
Anyway, I had an issue recently where we needed to load test 100+ machines, all booted from PXE. All machines were fresh out the box and all ethernet adaptors were fully registered in SCCM in the ignore list. In short, there was no reason for any machine not to PXE boot as expected. All went well until the 29th machine and then every machine thereafter refused to PXE boot. However, they did still receive an IP address. Additionally, the message Server response timeout E-18 flashed up very quickly before booting from the SSD.
Digging a little further, the machines that were able to PXE boot fine had to receive an IP address between .2 and .31 to work. Any IP after just refused to work. Having accepted that all was well from a firewall perspective, I was forced to concede that the problem was somehow local.
To cut a long and boring story short, the problem turned out to be a mis-configured subnet mask on the PXE server, in this case 255.255.255.224 instead of the 255.255.255.0 that it was supposed to be. The PXE server itself was allocated an IP within the range of PXE bootable clients and anything outside the range didn’t work. So easy when you know but one expects the basics to be correct so it took a while to track down. Hopefully this will provide some more ideas for anyone else who finds themselves with a similar issues.
I recently had an issue where a site seemed to suddenly stop communicating with it’s management point and the SUP. Whilst I never got to the bottom why it actually happened (given that all was working fine a day or two before) I did eventually get to the bottom of how to fix it but it took a good day out of a very busy schedule.
Anyway, the symptoms were an MP and SUP which could no longer communicate with the SQL DB. The logs would have errors similar to ‘Call to HttpSendRequestSync failed for port 80 with status code 500’.
As you can see, what a mess. This was working fine previously!
The MP in question was on the same domain and used the computer account to communicate with the database which was on the primary site server. I had also configured an account to connect to another forest on the SCCM site but this wasn’t used in conjunction with this MP. After banging my head against a wall for an hour or two I nonetheless decided to remove the forest connection account from ConfigMgr but still the same error. I then came across this post which I applied. This caused the mpcontrol.log and the WSUSCtrl.log to both calm down somewhat:
OK both logs looked better but we’re still stuck with errors. I decided to take a look back at the SPNs for SQL. I opened ADSIEDIT, found the SQL account in question and looked at the Service Principal Names registered. Sure enough they seemed to be registered with the NETBIOS and FQDNs all as expected.
Balls. I was running out of ideas.
I had a chat to my SQL guy and he suggested running Kerberos Configuration Manager just in case. This utility will check if the SPNs are registered correctly, and if not register them all correctly for you. Basically, it takes the messing about out of the command line. I wish I’d known about this utility years ago. Sure enough, it said one of the registrations was incorrect for some reason and it ‘corrected’ it. These worked fine the day before so why had one stopped working?? Doesn’t matter, just need to fix…
After that everything started working again. I was happy. Hopefully this will help someone else frustrated with bugs they didn’t know of in SCCM and SPNs that look, for all intents and purposes, like they are otherwise registered.
We were trying to build some Lenovo T470Ps and one was exhibiting this error just before the task sequence was to start and failed as a result before we even got off the ground. The error translates to The system cannot find the drive specified. However I knew for a fact that the drivers were OK as other T470Ps were building fine.
Transpires that somewhere along the way, something had indeed got mixed up on the disk and it was having problems with the config. I initially tried a DISKPART then CLEAN but this wasn’t enough and it was continuing to fail.
In the end I resorted to doing the task sequence’s job manually and recreating the partitions as follows:
Open CMD prompt (F8):
2. Select disk 0 (0 being the disk to setup)
4. Convert gpt
5. Create partition efi size=300
6. Format quick fs=FAT32
7. Create partition msr size=128
8. Create partition primary
9. Assign letter=c
10.Format quick fs=NTFS
Exit DISKPART and try again – this time the task sequence continued as expected.
This is something I’ve meant to get round to writing about for months as the first time I did this I couldn’t find any direct answers in the multitude of blogs I read about it.
On the face of things, installing WSUS/SUP on a secondary site sounds pretty straightforward if you’re used to adding them to a primary site but when you start it soon becomes clear there are a few unanswered questions which start to materialise. It’s important to first consider whether a SUP is even required for the secondary site: remember, the update packages will be present anyway. The secondary site SUP is really only there for scanning purposes and to relieve associated traffic which is really quite minimal. Assuming you are over this and need it anyway then here are a few other things to consider, some of which have changed since CM2007.
Since CM2012, there is now a DB on the secondary site so should we be installing to that?
How does it interact with the Primary SUP?
This blog is only intended to answer one or two questions you might have as regards specifics of installing on a secondary site and there are plenty of answers out there for general installation. In short, the SUP on the secondary site is a secondary SUP and when you install it ConfigMgr will actually take care of marrying it up to the Primary SUP.
So the high level tasks are as follows:
Install the pre-req’s for a Software Update Point. I thoroughly recommend Nickalaj A’s PreRequisite Tool for this job, see https://gallery.technet.microsoft.com/ConfigMgr-2012-R2-e52919cd. I must confess this has made me lazy and I barely remember what the pre-reqs are these days but to be honest I don’t need to with this.
Install the database on the secondary site SQL instance. Best practice is to have separate instances but I’ll leave that to you. Personally I don’t find there is any real performance issues using the same instance. Also, as an aside, if you have full SQL on the primary, (and you will) then I don’t really see why you wouldn’t use it on the secondary. Why use SQL Express when the licence is free for the full version? Just my opinion though.
WSUS Content should always be local. It’s a requirement to specify this during installation but it’s not really used when part of a SUP in ConfigMgr.
Finally, after WSUS installation, add the SUP role to the site. ConfigMgr will take care of the rest. Click on the secondary site under the Sites node, and click the SUP under the site component properties to check the sync status. It should be greyed out because SCCM has recognised it as a child of the primary SUP.
Recently been testing an upgrade scenario from ConfigMgr 2012 SP2 to Current Branch 1702 and during the course of putting together the legacy environment I came across a strange issue I’d not seen before. Essentially it goes like this:
A new OSD task sequence is created (doesn’t matter whether it is MDT-infused or not) and is deployed to All Unknown Computers. In my case I was using boot media to reach the WinPE environment on my test VM but there were no task sequences displayed. Checking the smsts.log file in the WinPE environment, it suggests that no policies are found.
The first time this happened the task sequence eventually appeared after about an hour or so. The next day I created a new one and exactly the same thing happened, with just the old TS showing up. I then saw this thread and changed my new task sequence availability time back 1 day. Et voila, the task sequence appeared.
Hope this helps anyone else scratching their head…
I noticed recently that after an extended period of being switched off, the Software Update Point in SCCM lab looked extremely poorly. I’m not sure why this was or if it had anything to do with being switched off for several days but in any case here is the scenario:
WSUS lives on a separate server to my site server and SQL is on another separate box (I know, better to install it on the same box as site server but I find few customers these days that’ll let me do this so I keep it this way to replicate their environments as far as possible). Anyway I digress; the setup is as follows:
Comms:HTTPS / SSL throughout for SCCM and for WSUS. Version:Current Branch 1606 OS: Server 2012 R2 (WSUS 6.2, commonly referred to as WSUS 4.0)
After noticing some errors in my component status messages with regard to WSUS, I checked the WSUSCtrl.log and saw the following message appearing every minute or so:
System.Net.WebException: The request failed with HTTP status 401: Unauthorized.~~ at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object args)~~ at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer()~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber)
Failures reported during periodic health check by the WSUS Server UT1.BC.LOCAL. Will retry check in 1 minutes
Furthermore, if I ran WSUSUtil checkhealth on the SUP, my Application Log read as follows:
The Reporting Web Service is not working.
The API Remoting Web Service is not working.
The Server Synchronization Web Service is not working.
The Client Web Service is not working.
The SimpleAuth Web Service is not working.
The DSS Authentication Web Service is not working.
On 13/10/2016 19:56:06, component SMS_WSUS_CONTROL_MANAGER on computer UT1.TEST.LOCAL reported: WSUS Control Manager failed to configure proxy settings on WSUS Server "UT1.TEST.LOCAL".
Possible cause: WSUS Server version 3.0 SP2 or above is not installed or cannot be contacted.
Solution: Verify that the WSUS Server version 3.0 SP2 or greater is installed. Verify that the IIS ports configured in the site are same as those configured on the WSUS IIS website.You can receive failure because proxy is set but proxy name is not specified or proxy server port is invalid.
Not good. Fortunately the fix was straightforward:
I ran c:\Program Files\Update Services\Tools\wsusutil.exe configuressl ut1.test.local
and then I saw URL: https://ut1.test.local:8531 appear on the screen.
Then restarted the IIS services (IISAdmin, WWW) and all sprang to life. An IISReset would probably have done the same thing. After this the log should start to look like that below.
(Open image in a new tab to see more clearly)
Assuming you are configured for SSL and for some reason you see something like URL: http://ut1.test.local:8530 instead, then most likely the SSL settings for WSUS are probably incorrect. Ensure you have the settings below in place in IIS:
1. WSUS Administration. SSL Settings should be unchecked / ignore.
2. ApiRemoting30. SSL settings should be checked / ignore.
3. aspnet_client. SSL settings should be unchecked / ignore.
4. ClientWebService. SSL settings should be checked /ignore
5. Content. SSL settings should be unchecked / ignore.
6. DSSAuthWebService. SSL settings should be checked/ ignore.
7. Inventory. SSL settings should be unchecked / ignore.
8. ReportingWebService. SSL settings should be unchecked / ignore.
9. SelfUpdate. SSL settings should be unchecked / ignore.
10. ServerSyncWebService. SSL settings should be checked / ignore.
11. SimpleAuthWebService. SSL settings should be checked / ignore.
Headaches of an SCCM Admin. But no other symptoms yet.