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.
One of the main criticisms of using web services is that they’re inherently insecure. By default anyone can access them and if they have functions to actually change anything then one must proceed with caution.
My current client was somewhat skeptical about their introduction and the only way I could bring them round to the wonderful gifts that they offer was to promise that we’d investigate a secure way to present them. There was some trial and error but I think we came up with a pretty good solution which I shall share here.
Why use web services at all?
There are an awful lot of reasons so I’ll keep it to why I like to use them. They’re a cheap and cheerful way to provide functionality by proxy. They can be used to off-load many tasks which, if you don’t have the budget for something like the wonderful System Center Orchestrator product, can make a great shoe-in. OK a little more explanation…
From a deployment perspective they can provide a mechanism to access Active Directory, MDT and SCCM without a client OS necessarily being part of AD. For example, they could be called from a WinPE session to update a database or query/update an OU. They’re relatively easy to write if you possess basic programming skills but if not, then I fully recommend you check out Maik Koster’s toolset here. Installation instructions are provided but do fall a little short on security, so let me crack on.
Securing the Web Services
First of all, if you run a PKI infrastructure, let me recommend you you change the URL to run under HTTPS. I am not going into detail in this respect here as there are plenty of how-to’s on this topic elsewhere on the web. Suffice to say it’s a no-brainer if you’re truly concerned about security, particularly if there are any services which need to pass confidential information such as passwords.
Next, ensure you have read Maik’s security blog for his web services. They’re basic but a good start. Now to secure it properly:
Securing the website via pass-through authentication
Follow these steps to lock down page to an AD group. I won’t go into detail on clicky-clicky, I assume if you have come this far you’ll know this stuff from within IIS and from the screen shots provided. If enough people tell me otherwise, I’ll review this though.
Before changing anything, this is the expected configuration:
2. Install url authorisation feature and windows authentication features from server manager or Powershell.
3. After installation, change authentication model as follows (apologies, image is a little blurry, I’ll try to update in due course).
4. Update Authorisation rules. Note that All Users verbs have been changed to POST. This prevents the web page appearing at all without a login prompt (ie the initial GET action is prevented from running) for all users other than those in that are members of the specified AD group.
5. Providers should remain at their defaults:
6. Update local Intranet sites. If the site isn’t trusted you may need to add this to local intranet sites to prevent a login box appearing.
You should now have full pass-through authentication for your web service, dependent on membership of the AD group of your choice.
So you’re testing out deployment of the new 1607 feature upgrade for Windows 10 in your shiny new 1606 SCCM console. The upgrade appears in your client’s Software Center and starts downloading* and then installing…and then disaster. You are hit with the dreaded message The software change returned error code 0xC1800118(-1048575720). Some Googling reveals a lot of the same responses, ie that you’ve allegedly forgotten to apply KB3159706 before synchronising. (Just in case this happens to be the case, check out the MS blog with appropriate links) but of course you we all know you applied that correctly, so what else?
It goes without saying that if you’re up and running with the official advice then leave as is and don’t fiddle further unnecessarily. However, if you’re still reading then the chances are that that isn’t the case. Well there are a number of other solutions describing how you must add the MIME type for the WSUS server as follows:
Try these for sure. Ensure you restart the IIS web services after adding the entry.
Again, however, this didn’t fix my issue. Maybe I was looking in the wrong places but I could find no information on the internet which fitted my particular set of circumstances, although there appear to be many in the same boat with unanswered forum posts.
After some head-scratching I did find a solution that worked. I simply reinstalled the the SCCM client agent from the client folder on the site server. Huh? This didn’t make too much sense to me until I took a closer look at the client version number before and after.
My freshly-built Windows 10 1511 builds were installing with client version 5.00.8355.1307:
After re-installation of the new client, the version number was 5.00.8412.1307:
Following this I was able to make the feature upgrade run without error. Subsequent SCCM servicing upgrades also upgraded the client files in this directory and the new client version has clearly fixed some compatibility issues with the 1607 feature upgrade.
I updated the default SCCM client version in the console and ensured all new 1511 builds were running the newer client version. Sure enough, feature updates worked perfectly following every new build. I then rolled out the new client agent version to my existing estate. This will obviously be a pre-requisite to ensure all machines upgrade as expected when the 1607 feature upgrade is rolled out wholesale.
Hope these tips help someone else suffering with upgrade frustrations.
* Another issue I have seen is where the feature upgrade gets stuck downloading at 0%. I solved this problem by simply creating a new package and re-downloading the feature upgrade and re-deploying.
A really quick post on an issue I had the other week.
The environment was https and all appropriate certs were in place. The production environment was working perfectly but in dev, when we used the FQDN to reach the report server we kept getting prompted for credentials. After double checking everything was set up exactly as I’d set it up for prod I found the credentials kept appearing. I tested the scenario without https and there were no prompts.
I added the site to the local intranet sites in IE and the prompting went away. A GPO might be called for if you experience this in an enterprise environment.
Headaches of an SCCM Admin. But no other symptoms yet.