Had this recently in an SCCM 2007 environment. After a bit of poking around I decided to reinstall the management point but this failed to fix the problem. Looking in the MPSetup.log is the error:
Fatal MSI Error – mp.msi could not be installed
After ensuring all the WebDAV setting were correct I started to scratch my head a bit before seeing one or two forum entries which suggested fairly major surgery but crucially included the step to run CCMClean. Well, this did make me think and I checked the SCCM client on the primary site. This was a lab environment and there was an overlapping boundary which caused a CM2012 client to be installed on this box.
Resolution:
I simply removed this client, removed and reinstalled the MP and everything was fine.
I recently needed to update the templates of our VMWare servers to reduce the amount of patching required after each deployment. IMO it’s good practice to do this every six months or so and reduces the time it takes for the server to be in a state that is ready for business.
Our template is essentially a non-domain-connected workgroup with no licence key as you’d expect (this all gets added during the orchestration process). As such this presents additional challenges as regards deployment from SCCM which would typically be to a domain-joined machine. The process below can be used for any deployment to a workgroup-based machine of any type from SCCM, it just so happens I need to do this for software updates to a server.
1.) Ensure you have a local administrative account set up on the workgroup machine, eg %computername%\SBond in my example below.
2.) RDP onto the machine using account above. Copy the CM2012 client install folder from a site server (eg Primary or MP) and paste it via an RDP session on the desktop.
TIP: Copy over CMTrace.exe too, you’ll more than likely use it for something.
3.) Add the local account to ConfigMgr:
4.) Bring up an administrative cmd prompt and CD to C:\Users\<localuser>\Desktop\Client. Run the following command (update as appropriate):
5.) Recommended: Depending on your setup, you may wish to add the following registry entry for preferred MPs. Select at least one MP on the same subnet as your machine:
This should stop much of the noise you’ll get trying to contact MPs you’re not interested in. This might be the case if you have cross forest relationships, etc. This step can safely be ignored if your configuration is reasonably simple.
6.) Leave for 10 mins or so and then find machine in ConfigMgr. Right-click and select Approve.
7.) Open the CM Client applet and if you don’t already have all the tabs you’d expect usually ~7) then click Machine Policy Refresh under theActionstab and Find Site under the Site Tab. Give it a few more minutes and the tabs should all appear.
8.) Finally, Add the computer to the appropriate patch collection and wait for patches to download. Ensure there are no further patches to run after reboot.
9.) Remember to remove the registry entries from earlier before handing back the machine!
NOTE
1.) In my case, because the template machine hasn’t been deployed, it doesn’t have a licence. If you select to run the software update scan cycle you’ll see a popup like that below. You can safely ignore this, it will still install the updates. You will also see this popup from time to time just before they start installing. Just ignore it.
“You may be a victim of software counterfeiting.”
2.) I noticed all the machines had the same name. Because they’re in a workgroup, this is acceptable to CM and had no noticeable detrimental impact on deployment.
So I finally received the long awaited delivery of my Surface Pro 4 i7 16GB 512SSD. Once accompanying products have been purchased (keyboard, mouse, etc) this was a purchase in excess of £2K. I justified this to myself because this could realistically support a mini Hyper-V and dev environment on a device which really was truly portable. A proper OS makes this a truly useful and exciting device.
My excitement was however short-lived when I discovered the performance of the SSD was awful. Worse, in fact, than the Surface 3! If I’m paying top dollar I want top spec and was set to send my Surface back to Microsoft. I then read on various forums that Microsoft had sourced their SSDs for the top-end models from two different manufacturers, Samsung and Toshiba. Unfortunately it appears most people have received hardware with the Samsung drives in which are slower. These drives, while reasonably fast to read (1200+ MB/s) were exceptionally slow to write (average around ~150MB/s). Compare this with the Toshiba drive or Surface Pro 3 which was around five times faster!
Anyway, following some digging it appears Samsung have released a firmware update for their SSD which brings it back into line. For typical bench scores after the applied update, see below. In short, this is a must-have update, almost as important as the various stability updates around. Download here.
UPDATE:
The link above seems to be constantly ‘busy’. I fortunately still have a copy of the driver which you should be able to access here. Also, if you have downloaded the May 2016 drivers, I have written an update post.
You may also see the following message in the ScanAgent.log:
Sources are current, but Invalid. TTL is also invalid.
SCANAGENT.log
WUAHANDLER.log
1. You’ve tried reinstalling the client.
2. You’ve installed Windows6.1-KB3050265-x64
3. Maybe even https://support.microsoft.com/en-gb/kb/2887535
Errors just won’t disappear…well help is at hand.
These errors translate to the following:
0x8007000E -2147024882 E_OUTOFMEMORY 0x8007000E -2147024882 [DCOM belly up] CAgent::CreateJob failed Not enough storage is available to complete this operation.
and
0xC80003F3 -939523085 hrOutOfMemory The computer is out of memory
However, you look at the available memory and can clearly see there is plenty to be playing with.
SOLUTION:
Turns out you need to up the pagefile on the affected box – this shouldn’t even require a reboot and immediately the errors will disappear from the logs and lovely software updates will all appear in Software Center.
One slight oddity I did notice was that while the software updates appeared, they wouldn’t start downloading/installing. I waited quite while and they just seemed to sit there. I restarted the SMSAgent host and this cleared them but wouldn’t pick them up again despite manually instigating the Scan or Software Updates Deployment actions from the SMS agent applet. I needed to restart the box, and then run these actions again manually after that and all started to work as expected and start downloading/installing.
You try to deploy software updates to a system and no updates will install. The system picks up the updates, tries to install but ultimately fails after hanging for ages. Eventually you are presented with the error above.
Resolution
BITS is most likely not running. It is unlikely it isn’t installed as you would expect it to be installed if the ConfigMgr agent is installed but it may not be running. Start the service and try again.
All servers in our a newly-formed environment required a first set of ‘baseline’ patches to bring them up to speed, after which we would set up a monthly patch update schedule.
Following this ‘inaugural’ deployment of around 380 patches. everything appeared on the face of things, to go smoothly. Machines all received updates and rebooted as expected. I could see from reports however that one or two patches had failed to install for some reason in this deployment. I figured that we could schedule in another time to try these again, maybe even the following month as none were actually deemed critical. In any case this was another conversation I needed to have with the application owners.
Two days later I got a call saying that a sizeable percentage of the server collection I had patched ‘randomly’ rebooted again at various times that morning. A significant amount of arm waving ensued and I was asked to look into it, especially as it was clear from the event logs that the reboot had been instigated by the CCMExec:
The process C:\Windows\CCM\CcmExec.exe (COMPNAMEXXX) has initiated the restart of computer COMPNAMEXXX on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found
Reason Code: 0x80020001
Shutdown Type: restart
Comment: Your computer will restart at 08/14/2015 09:58:37 AM to complete the installation of applications and software updates
I frantically checked all deployments and confirmed there was absolutely no deployments due and everything had basically gone out as expected. In fact nobody had even touched the console that morning. Further digging revealed the following in the logs of affected machines:
Log Name: System
Source: Microsoft-Windows-WindowsUpdateClient
Date: 12/08/2015 17:24:00
Event ID: 20
Task Category: Windows Update Agent
Level: Error
Keywords: Failure,Installation
User: SYSTEM
Computer: COMPNAMEXXX.domain.local
Description:
Installation Failure: Windows failed to install the following update with error 0x80092004: Update for Windows Server 2008 R2 x64 Edition (KB3045645).
Then, later on:
Log Name: System
Source: Microsoft-Windows-WindowsUpdateClient
Date: 14/08/2015 10:02:43
Event ID: 19
Task Category: Windows Update Agent
Level: Information
Keywords: Success,Installation
User: SYSTEM
Computer: COMPNAMEXXX.domain.local
Description:
Installation Successful: Windows successfully installed the following update: Update for Windows Server 2008 R2 x64 Edition (KB3045645)
Similar entries appeared for several of the failed updates. Clearly what had happened is that another software update scan cycle had taken place and detected that the machine was missing several important updates, specifically those that had failed previously. The updates were then automatically re-tried and successfully installed the second time round. Presumably they needed a reboot before they would install correctly although I have read plenty to suggest this shouldn’t happen. Regardless, the second successful installation instigated our phantom reboots.
My recommendation here would be to ensure you have a dedicated Maintenance Window to alleviate this headache. There were one or two that picked these updates up and installed them after my discovery and the Maintenance Window prevented the reboot from occurring. Obviously it won’t be properly patched until the client has been restarted but that can at least be left to the application owner to decide on a suitable time to do this.
Very short and (not so) sweet post with a word of warning on ADRs.
CM2012 SP1 R2
I wanted to set up and Automatic Deployment Rule to select a bunch of updates and automatically download and set up my Software Update Group. In my client’s environment the only box with internet access belongs to the SUP. Unfortunately, if you want your ADR to carry out the tasks above then you will need to ensure your Primary Site Server has access to the internet as well.
An ADR will always fire from the Primary Site Server and without internet access, the ADR will fail to download any updates.
This is an issue that can occur in any situation where a site system role requires a certificate. I have seen it happen when creating a new Management Point or creating a new PXE service point. In the situations I have been in, I find this tends to be profile-related so check that you’re logged on with a ‘proper’ profile, ie not temp, etc.
Assuming this is the case, follow the steps below.
THE FIX
1. Go to C:\Users\<USER ACCOUNT>\AppData\Roaming\Microsoft\Crypto\RSA\<GUID>
2. Delete GUID files within.
3. I restart SMSAgent Host (maybe required)
4. Try again. The GUID files will automatically be recreated and you should be able to proceed with the cert creation.
I recently wrote a GUI to duplicate MDT database roles based on the excellent Powershell commandlets written by Michael Niehaus: http://blogs.technet.com/b/mniehaus/archive/2009/05/15/manipulating-the-microsoft-deployment-toolkit-database-using-powershell.aspx.
Although the Powershell code worked fine when executed directly in a Powershell window, I was seeing mixed results when executing the same code in C# through PowershellInstance.invoke(). Specifically, when I compiled the executable I was able to run the powershell code through the utility without issue, whereas it failed for my colleagues for some reason.
THE FIX
It seems that what I needed to do was ensure that the code was compiled specifically for the platform I was running it on as opposed to ‘any CPU’. In my case this was for x64. You can set this under the project properties in Visual Studio:
However, after making this change, I found I was getting compilation errors along the lines of: An attempt was made to load an assembly with an incorrect format: [path to exe]
To fix this, I needed to change Generate serialization assemply to Off and everything compiled as expected. More on this here.
Just had this issue which was somewhat perplexing because normally when you get an error like this you tend to find there are missing tabs and maybe a missing site code. The location services log file was saying that there was no information being returned from the MP, yet as you can see from the image above everything looked otherwise intact.
RESOLUTION
When the client was installed, a Fallback Status Point was specified. A Fallback Status Point was installed on the primary site but it transpires that this isn’t enabled by default (at least it wasn’t in our case). Once this was enabled everything began working again:
(click image to enlarge)
Headaches of an SCCM Admin. But no other symptoms yet.
