Slow WinPE Boot Speed

, , , ,

Default out-of-the-box booting on WinPE with SCCM 2012/2016 is very slow. In some environments I’ve seen this take 3 hours to download the Boot.Wim. This is because System Center Configuration Manager 2012/2016 uses small TFTP block sizes of 512 bytes.

This behavior is set because it’s compatible with all network configurations; but the result is that the PXE boot speed can be very slow using Operating System Deployment with SCCM.

To increase the PXE boot speed, we need to modify TFTP Block Size.
In the registry editor:
Path : HKEY_LOCAL_MACHINESOFTWAREMicrosoftSMSDP
Name : RamDiskTFTPBlockSize
Type : REG_DWORD
Value : 16384 (decimal)

16384 is the maximum supported value.
If it is bigger, you can have corrupted data.
However I recommend to do some test with values :
– 4096,
– 8192,
– 16384.
I typically run 16384 and 8182 in my environments. These will be DP that are on server 2008R2 and later.

Restart the Windows Deployment Services Service. (WDS)

On this particular PXE-DP the time to download the boot.wim increased by roughly 80%

To my knowledge this feature has been built into CB1606 but I have not moved there yet to test myself.

ALSO SEE : Rebuild site servers without redistributing content over the WAN

Secondary Site stuck in “Deleting” state

, , ,

I recommend when decommissioning a site server to first remove any additional roles such as DP before uninstalling the site. The site removal will move through these motions for you but I just remove the roles before hand out of habit. This post will assume boundaries have already been updated.

From the console after you removed your additional system roles (such as DP) it is time to uninstall the site server.

When to Uninstall:
Use this option to remove a functional secondary site that is accessible from the network. This option uninstalls Configuration Manager from the secondary site server, and then deletes all information about the site and its resources from the Configuration Manager hierarchy. If Configuration Manager installed SQL Server Express as part of the secondary site installation, Configuration Manager will uninstall SQL Express when it uninstalls the secondary site. If SQL Server Express was installed before you installed the secondary site, Configuration Manager will not uninstall SQL Server Express.

When to remove:
A site has failed to install or when the site remains visible in the ConfigMgr console after you’ve uninstalled it

How to Monitor:
On your secondary site server you can monitor this from C:ConfigMgrSetup.log. The site server uninstallation process is roughly as follows.

1. ConfigMgr2012 Setup is started by system with command line options /deinstall / msg2parent /nouserinput

2. Information is checked, this will be things such as the following. FQDN, OS is verified, Checks for existing setup information, existing SQL information, existing configmgr installation and version number, etc.

 

3. removes SQL alias for sccm

4. Starts uninstallation of secondary site by first cleaning up SQl server replication data, start uninstallation of local dp (if applicable) Remove content SCCMContentLib, SMSPKG, SMSPKGF$, SMSSIG$ directories from the server. The process will also move through list of all SCCM Services and stop/uninstall them if present and then stop WMI

 

 

NOTE: After services/connections are removed you will see a number of redlines in the log file. This is only b/c connection can not be established which is expected right after stopping WMI

 

5. Connect to database, drop schema SMS_SiteSystemToSQLConnection, drop database, and uninstall SQL (if applicable)

 

NOTE: ONLY If your admin installed SQL instead of letting SCCM perform the uninstall action during site install you will see this message

6. Attempt unregister list of Binaries

7. Attempt delete remaining folders/files from within the configmgr installation directory

8. remove registry keys, restart WMI, and other services then complete uninstallation of Configuration Manager Site.

This is great according to the log files the site is completely uninstalled, but why is nothing changed in the console after 3 hours?

 

This is still showing Deleting even after restarting the old secondary site and primary server. Do not worry because this fix is something that I have ran into before. We will have to use the hierarchy Maintenance Tool (Preinst.exe)

========================================================================

1. on primary site server launch command prompt as administrator > Navigate installation location of configmgr

2. run the following command

preinst.exe /delsite SUF

 

After this command executes successfully refresh the console and search for the site server you will see it is gone.

of course in your environment you might have configmgr installed on a different drive, and different site codes so modify where necessary.

In a future blogpost I will cover the full process to convert a secondary site server into a DP. This is in efforts to meet pre-req check on the ongoing hierarchy upgrade to 1610. The reason these secondary sites will fail is b/c the current version of SQL express is not compatible.

 

ALSO SEE : Things to check after site recovery

Things to check after site recovery

, ,

Unfortunately I have found myself in a disaster scenario that required recovering one of our sites.
This is my list of identified problems from that experience. Please let me know if you have ran into more. Please first check everything listed from Microsoft here. It is important to reset your passwords in the console and apply all hotfixes.

1. Compliance items not showing up on SCCM Clients
– Resolved by redeploying the compliance items

2. Hardware Inventory/Asset Intelligence not being collected
– Resolved by recreating client settings and deploying

3. OSD Broken due to DP Certificate Store error
File:TmPx86x64{x.x.x.x.x.x.xx..x.x.x.x..x}.bcd
Status: 0xc0000098
Info: The Windows Boot Configuration data(BCD) file from the PXE server does not contain a valid operating system.
When you check the SMSPXE log, it shows the following message
PXE:: MP_LookupDevice failed 0x80092002
Failed to create certificate store from encoded certificate
– Resolved by Right click on DP under General and change the date for the self sign certificate

4. OSD Broken due to all unknown computers collection no longer contains members
– Resolved by recreating the unknown computers objects and adding to collection.

To recreate the collections, change the registry value of CreatedUnknownDDR under SOFTWAREMicrosoftSMSCOMPONENTSSMS_DISCOVERY_DATA_MANAGER on your primary site server (not the CAS). Set the value to 0.

Then, re-start the SMS_EXECUTIVE service. When the Discovery Data Manager (DDM) component starts, it will think that the Unknown System records have not been created, and will recreate them.

The above restored my unknown computers however it created duplicates. I went ahead and created a collection with those for the site code and then deployed my OSD task sequences as available. I tested against my test VM and successful deployment…or so I thought.

5. Reports that OSD was STILL Broken for 15% of systems due to duplicate unknown computers
– Resolved by removing the older unknown computer object directly from the sccm database

There are known issues after a site restore for duplicate unknown computer objects. When this occurs systems will not be able to identify which unknown object to identify with, and will not fall under the proper unknown collection. We have tried to create a collection with the duplicated/original computers but this will not work. Machines will attempt to pxe and return with the following.

PXE-E53: No boot filename received PXE-M0f: Exiting Intel PXE ROM. Operating system not found.

Typically in the past the solution is to go into the configmgr console and delete the duplicate object so it will now be able to view the advertisement to unknown computers collection.

Example of problem. This will show the duplicate objects for KW1.

I am in a CAS environment and I had to perform the restore on the CAS from my primary site servers database. I Launched SQL Mgnt studio on my primary and and ran the following query

select * from UnknownSystem_DISC

Pay attention to the far right column named Creation_Date0. These dates represent when the object was originally created (initial hierarchy implementation) and the date of site restore. We are looking for the dates on the duplicate unknown objects. The item keys need to be deleted for the older object.
Run this sql command

delete from UnknownSystem_DISC where ItemKey in (2046820352, 2046820353)

After this I decided now that I Have the two proper newly created unknown computers objects (x86 and x64)

my next action would to make a new unknown computers collection and redeploy my available task sequences.

Side note: Number 4/5 When I first tested OSD I must have been a test VM that was a known computer. When I tested OSD again I must have used another test VM that was an unknown computer. This was something that was overlooked at the time which lead me to believe OSD was 100% functional before I went on weekend vacation in Dubai. When I returned from partying it was reported that some systems were still having problems with OSD.

Yes… I know it is against Microsoft best practice to deploy to all systems however this is what the customer required. Roughly 90%+ of all systems imaged at the site are existing known objects.

 

ALSO SEE : Start Windows Update Service Compliance item