Error installing Windows ADK

No Gravatar

When preparing a new Windows Server 2012 R2 system for a new ConfigMgr 2012 R2 site, I ran into an error installing the Windows ADK.  In this case it is version 10; however, I believe the same scenario would apply to 8.1 Update, 8.1, 8, etc. 

The installation appears to be working, then performs a rollback with the following error:

image

Image path is [\??\C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\wimmount.sys

Could not acquire privileges; GLE=0x514

Returning status 0x514

Solution / Workaround

What eventually worked around the problem was to run the installation as the SYSTEM account.

image

Getting to the workaround

Multiple other solutions were attempted before resorting to the SYSTEM account for installation including

  • Run as Administrator
  • Run a Command Prompt as Administrator then run ‘ADKsetup.exe
  • multiple system reboots
  • manually creating the folder structure and file
  • manually running the ‘Windows Deployment Tools-x86_en-us.msi‘.  Strangely this succeeded; however, when re-running the ADKsetup.exe, the same failure occurred.
  • manually running the ‘Windows System Image Manager on amd64-x86_en-us.msi‘.  Strangely this succeeded; however, when re-running the ADKsetup.exe, the same failure occurred.
  • both the system drive (Drive C:) and a data drive (E:) were attempted
  • disabling the antivirus / antimalware software (Sophos)

None of these made any difference.

Several forum posts were found with a resolution pointing to a blog that has since been taken down.  That solution required removing the computer from the domain.  This solution was not attempted.

Executing the workaround

There are a few ways to gain SYSTEM account access; however, I took the interactive route and used PSEXEC from Sysinternals.

From an elevated Command Prompt (Run as Administrator), run ‘PSEXEC.exe -s -d -i cmd.exe

A new Command Prompt will be generated.  run ‘whoami‘ to ensure you are running as SYSTEM, then run ‘adksetup.exe

 

Thanks to Adam for working through the issue with me.

August 17, 2015

Posted In: Uncategorized

NTFRS or DFS-R replication for SYSVOL

No Gravatar

For a recent customer I was going through all of the requirements to implement DirectAccess.  One that I stumbled on a bit was that DirectAccess requires DFS-R replication but I wasn’t certain how to verify what replication type was in use.  After some digging, some assumptions, and some great tips from fellow Catapult Systems consultants, here’s the scoop.

Determine if FRS is being utilized by the Domain Controllers

Note: FRS is the abbreviated acronym for NTFRS.

Method 1

From an administrator Command Prompt on a domain controller run DfsrMig /GetMigrationState and DfsrMig /GetGlobalState

  • A value of 0, 1, or 2 means the migration from FRS to DFS-R is in progress
  • A value of 3 means the migration from FRS to DFS-R is complete (FRS is ELIMINATED)
  • A return message of "DFSR migration has not yet initialized" means FRS is in use, not DFS-R

Method 2

From ADSI Edit or Active Directory Users and Computers with Advanced Features enabled,

navigate to <domain>\System

  • if a container named DFSR-GlobalSettings exists, then DFS-R should be in use
  • if a container named File Replication Service \ Domain System Volume (SYSVOL share) exists and contains Domain Controller objects, then FRS should be in use

navigate to <domain>\Domain Controllers\<Domain controller>\

  • if a container named NTFRS Subscriptions exists, then FRS should be in use

Method 3

From a domain controller

  • open Event Viewer \ Applications and Services Logs\ File Replication Service.  If there is recent activity then FRS should be in use.
  • if <SYSVOL>\SYSVOL_DFSR\SYSVOL exists, then DFS-R should be in use.

Note: to find the <SYSVOL> share

  • From a command prompt enter reg.exe query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters and note the SysVol location
  • From a command prompt enter dir %SystemRoot%\SYSVOL\SYSVOL and note the location of the <domain FQDN> directory junction which will be in [square brackets]
  • From ADSI Edit or Active Directory Users and Computers, check the fRSRootPath attribute of the <domain>\Domain Controllers\<domain controller>\NTFRS Subscriptions\Domain System Volume (SYSVOL share) object

References

July 27, 2015

Posted In: Uncategorized

Tags:

What’s my ConfigMgr version: 2012 SP2 or 2012 R2 SP1?

No Gravatar

I’ve been installing a few lab and production ConfigMgr environments recently and found a little quirk with the versioning to go along with the service pack madness / confusion of the 2012 SP2 / 2012 R2 SP1 release.  Here’s the scoop:

After installing ConfigMgr 2012 SP2 as a new / fresh install, how do you know if R2 is installed?  There are really only two ways I can find:

  1. Launch the Configuration Manger Admin Console and check the about screen.  The console version will be 5.0.8239.1000 and the site version 5.00.8239.1000 for both SP2 / R2 SP1; however the product name will show “System Center 2012 R2 Configuration Manager SP1” or “System Center 2012 Configuration Manager SP2” to indicate the difference.
  2. Review the 2012 R2 release notes (What’s New in System Center 2012 R2 Configuration Manager) and note the new features.  If these exist within the Admin Console on the connected site, then R2 is installed.  Probably the easiest check is in Software Library –> Operating Systems –> Virtual Hard Disks.  The VHD feature set is part of R2 and won’t exist in a non-R2 site.

 

image

 

Some additional details

Where can the R2 installer be download from?

  • If installing ConfigMgr 2012 SP2 / 2012 R2 SP1 from evaluation media, you’ll easily notice that there are 2 files to download and install.  The small (1.1 mb) file is the “R2” installer / enabler.  Otherwise the code base is identical between the versions / editions.
  • If installing from MVL media, the small “R2” installer may not exist for download.  I’ve only see 1 company’s MVL site and the file didn’t exist in any place we could think to look.  Installing “R2” from the evaluation file, SC2012_R2_SP1_ConfigMgr.exe, worked fine on multiple MVL installed sites.

When I installed R2, there were almost no indications of the change.

  • The actual install, ConfigMgr2012R2SP1.msi did not generate a log file that I could find
  • The Windows Application Event Log did show that “Product Name: Microsoft System Center Configuration manager. Product Version : 5.00.8239.1000 … Reconfiguration” succeeded, but notice that the name does not identify SP2 or R2 SP1.
  • C:\ConfigMgrSetup.log was not changed
  • C:\ConfigMgrAdminUISetup.log was not changed
  • C:\ConfigMgrAdminUISetupVerbose.log was not changed
  • I could see no entries in any ConfigMgr site logs that gave any reference to a change
  • I could see no changes in the Windows Registry at HKLM\Software\Microsoft\SMS\*
  • The site properties in the Admin Console showed no changes
  • Re-running the R2 installation gave no indication that it was already installed
  • Re-running the R2 installation (ConfigMgr2012R2SP1.msi) with verbose logging did create a log file but there was no indication that it was already installed
  • Windows Programs and Features (Add / Remove Programs) did not change the product name

 

So much for clarity!

June 16, 2015

Posted In: Uncategorized

Tags:

BITS error 0x80200013 during ConfigMgr client installation

No Gravatar

When attempting to install the ConfigMgr / SCCM client on a few remote computers, the installation failed (more like stalled out) when ccmsetup.exe tried to download the full client binary files.  The download couldn’t complete and the following error was generated:

Failed to download files through BITS. Error: 0x80200013, Description The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.

I discovered that Microsoft KB922330 describes the issues and a workaround.

You may experience this problem if a computer is behind a firewall or behind a proxy server. This problem occurs if one of the following conditions is true:

-The proxy server environment does not support the HTTP 1.1 range request feature.

-You are behind a SonicWALL firewall device, and the Enable HTTP Byte-Range request with Gateway AV setting is not enabled for the device.

When you copy a file by using BITS in background mode, the file is copied in multiple small parts. To perform this kind of copy operation, BITS uses the HTTP 1.1 Content-Range header. If you are behind a proxy server or behind a firewall that removes this header, the file copy operation is unsuccessful.

Note When BITS copies files in foreground mode, BITS does not use this header.

Interesting… changing the BITS priority will work around the issue and it just so happens that we can control that in the ConfigMgr client installation. 

Running ccmsetup.exe /BITSPriority:FOREGROUND did work around the BITS error during client installation.  The client successfully installed and registered with the Primary site.

We could also manually copy all of the installer binary files locally and use the /SOURCE parameter as another alternative.

 

Success!… well, not so fast.

 

From an ongoing operations perspective not much was gained.  Although Client Settings allow controlling BITS throttling, it cannot control BITS priority.  About a year ago the question about controlling BITS priority from a ConfigMgr content distribution perspective was asked on the TechNet forums and the product team did confirm that it isn’t a current feature.

 

It looks like the firewall or proxy server will have to be kicked in the shins after all.

 

Follow-up

I stumbled on to an interesting post by the 2PintSoftware guys whom have been doing A LOT of great work with BITS and BranchCache recently.

If I set the BITS Throttling Rate in SCCM, does it apply to all downloads?

Oh no. That would be too simple. Remember that the client setting in SCCM is for Background transfers only. So if you make a deployment ‘Available’ as opposed to ‘Required’, then it will be a BITS Foreground transfer that is created and it will attempt to use whatever bandwidth it can get it’s grubby little hands on.

http://2pintsoftware.com/2psfaqs/bits-throttling

So it appears that ConfigMgr does know about BITS priorities beyond the ccmsetup.exe scope, but you still can’t change it.

May 21, 2015

Posted In: Uncategorized

Tags:

ConfigMgr OSD and the HP Virtual Install Disk

No Gravatar

A recent customer was having an issue using ConfigMgr (SCCM) to deploy Windows on their new HP ProLiant Gen9 servers.  Their existing hardware models and virtual machines worked fine, but the new HP Gen9 models were failing with the following error in SMSTS.log:

Failed to write volume id file to disk <drive letter>:. 80070013
Failed to convert protected paths to unqiue ID. Error code 0x80070013
Failed to reboot the system. Error 0x(80070013)
Failed to initialize a system reboot. The media is write protected. (Error: 80070013; Source: Windows)
Fatal error is returned in check for reboot request of the action (Setup Windows and ConfigMgr).   The media is write protected. (Error: 80070013; Source: Windows)
An error (0x80070013) is encountered in execution of the task sequence
Task Sequence Engine failed! Code: 80070013
Task sequence execution failed with error code 80070013

This error occurs after the OS Image is installed and just before the first reboot which causes the Task Sequence to fail.

This is very similar to the error experienced in SCCM 2007 for with Microsoft released hotfix KB2516580 to resolve.

You perform the restart computer step in a task sequence and the embedded device has a RAM disk or has a hard disk drive that has no free disk space

Failed to get unique id (0x80070001)]
Failed to convert <drive letter> to unique volume id. Code : 0x80070001
Failed to convert protected paths to unqiue ID. Error code 0x80070001
Failed to reboot the system. Error 0x(80070001)
Failed to initialize a system reboot.

OR

Failed to reboot the system. Error 0x(80070070)
Failed to initialize a system reboot. There is not enough space on the disk. (Error: 80070070; Source: Windows)
Fatal error is returned in check for reboot request of the action (Disable Write Filter Action). There is not enough space on the disk. (Error: 80070070; Source: Windows)

The customer environment is ConfigMgr 2012 R2 CU3 so obviously the hotfix doesn’t apply.  However, pretty much the same scenario is in play.

Cause and Resolution

The root cause is the existence of the HP Virtual Install Disk (VID) which is read only.  While ConfigMgr should be able to handle the scenario, the easiest solution we found was to simply disable the VID.

Disabling the HP VID

To disable the HP VID, boot the server and press F9 to enter the BIOS/Platform Configuration (RBSU).  Then…

  • on an HP ProLiant Gen8 server: Advanced Options -> Advanced System ROM Options -> Virtual Install Disk -> disable -> F10 to save -> Reboot
  • on an HP ProLiant Gen9 server: System Options -> USB Options -> Virtual Install Disk -> disable -> F10 to save -> Reboot

May 18, 2015

Posted In: Uncategorized

Tags: