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.
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.
So you’re looking forward to upgrading to the next CB version of SCCM and growing frustrated at the fact there is nothing appearing in Updates and Servicing pane. In fact, there should be several hotfixes showing in addition to the latest and greatest version of ConfigMgr. But….nothing.
You can be logged in as a full administrator and nothing will appear!
Open the console as the user which installed ConfigMgr in the first instance. Failing this (user has since been deleted, etc) go to Administration | Security | Administrative Users and look for a user that has All instances of the objects that are related to the assigned security roles selected. The chances are, that the user you are having problems with doesn’t have this selected (yes, even if they’re a full admin) and this is the crux of the problem.
Now, open the console with the user who has this permission and you should now get a message saying that there are updates available. Go to the security node and make the appropriate changes described above to the users or groups that you wish to have access to this view.
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.
There has been a lot of talk about the use of SQL AlwaysOn Availability Groups (AOAGs) from SCCM 2012 onward but it wasn’t available in any iteration of this version and promises were made by Microsoft to include this is as a feature in 1511. Indeed it seems to have been planned and implemented in the Technical Previews but evidently didn’t make it into the final official release of 1511. Given that officially* you need to go via 1511 to install 1602 this is very annoying for anyone wishing to use this feature as a number of extra steps are required. Below I try to clear up much of the contradictory information available at present (May 2016) on the internet.
A number of websites run by respected MVP’s continue to suggest availability in several 1511 versions:
Technical Preview 1511 – This version is also known as the Configuration Manager Technical Preview 4. It represents a baseline for Technical Previews that begin with the release of the current branch for System Center Configuration Manager, version 1511…
This is where it gets interesting because Technical Preview 4 covers a number of separate releases which flank the ‘official’ 1511 release on Dec 8th 2015: https://buildnumbers.wordpress.com/sccm/
Well that that clears it up then.
After filtering through a good deal of contradictory information, it appears that SQL AOAGs made it into the 1512 TP4 version and that 1602 is the first official CB release to have full support.
So to be clear, when installing 1602 and above from scratch, install 1511 first by pointing to the single DB instance then change to AOAGs later via the procedure below.
If you don’t, and you are using the Dec 8th (official) release of 1511 then when adding the AV Listener you’ll see the following error message:
And nobody likes to see that 🙂
* I hesitate to say this but it is perfectly possible to install 1602 direct from certain media sources** for 1602.This is not supported and therefore not recommended, I am informed one of the side effects of doing this is that you’ll not be able to update in future. There may be other, undocumented side effects too.
** Media I obtained came from an unconfirmed source althoughit is possibleit may have been from CD.Latest (I didn’t originally source it so can’t confirm for definite). Basically don’t do it if you want a supported environment!
SCCM 2012 R2 SP1 with SCCM database on the same server.
So in a lab I upgraded my SCCM 2012 R2 SP1 instance to 1511. This is a Hyper-V environment running on my Surface Pro and I have SCCM, SQL and the SCCM admin console running on the same VM.
The upgrade itself appeared to go smoothly but when I opened the admin console I just got the grey screen telling me I was unable to connect and that I should check I had permissions and that the SMS provider was installed and available, etc. Obviously it was, it was on the same machine and I had been working with it 20 minutes beforehand.
My immediate reaction was something had gone wrong with the DB upgrade. I hadn’t run the /TestDBUpgrade switch as this was very much a test environment and I didn’t have another server I could quickly and easily test it with. I did however take a snapshot and reverted back. A few tweaks here and there and a re-run of the upgrade produced the same result. Then I decided to test whether this was actually a problem with the installation or simply a problem with the console.
I decided to try and build a machine off this install (PXE boot) and sure enough it built perfectly.
Next, I installed the 1511 console on another VM (my lab DC in this case) and sure enough again, it connected perfectly.
Next step, check the console logs, in particular the SMSAdminUI.log file under C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\AdminUILog. Under here I noticed that there were a number of performance counter errors eg as below:
[1, PID:844][04/08/2016 11:11:59] :The performance counter ‘# images’ was not found
[4, PID:844][04/08/2016 11:12:01] :The performance counter ‘# result objects in memory’ was not found
[4, PID:844][04/08/2016 11:12:01] :The performance counter ‘# exceptions’ was not found
Seems the upgrade broke the performance counter settings in some way so this needed fixing:
1. (Important) Open a command prompt and CD\Windows\SysWow64
2. LODCTR /R (ensure you are in the dir path above or you are likely to get error code 2).
3. Reinstall the console from the 1511 upgrade setup.
4. Et Voila, (hopefully) all should start working again.