I encountered an issue promoting a Server Core R2 to a domain controller. The DCPROMO on Server Core is handled via unattended mode with answer file. The error I received is below. It was due to Server Core’s inability to install/confirm ADDS binaries.
Checking if Active Directory Domain Services binaries are installed…
Failed to detect if Active Directory Domain Services binaries were installed. The error was: An error with no description has occurred.
And the DCPROMOUI.log also shed some light on the nature of the issue.
dcpromoui 504.204 001E 03:01:08.709 Unable to find identity string for package name Microsoft-Windows-ServerCore-Package
dcpromoui 504.204 001F 03:01:08.709 Failed to retrieve the parent package name
dcpromoui 504.204 0020 03:01:08.709 HRESULT = 0x800F0818
dcpromoui 504.204 0021 03:01:08.709 HRESULT = 0x800F0818
dcpromoui 504.31C 0022 03:01:08.709 HRESULT = 0x800F0818
dcpromoui 504.31C 0023 03:01:08.709 Enter GetErrorMessage 800F0818
My attempt to add the binaries via the DISM also failed.
dism /online /enable-feature /featurename:DirectoryServices-DomainController-ServerFoundation
Deployment Image Servicing and Management tool
Image Version: 6.1.7600.16385
DISM failed. No operation was performed.
For more information, review the log file.
The DISM log file can be found at C:WindowsLogsDISMdism.log
The OCSETUP attempt also failed sighting the same error.
After I had ensured that the OS was up-to-date with patches and updates, I stumbled upon System Update Readiness Tool KB947821. What is System Update Readiness Tool ? it is a patch that helps you find the inconsistencies with system files.
System resources, such as file data, registry data, and even in-memory data, can develop inconsistencies during the lifetime of the operating system. These inconsistencies might be caused by various hardware failures or might be caused by software issues. In some cases, these inconsistencies can affect the Windows servicing store, and they can cause software updates not to work. The System Update Readiness Tool tries to resolve these inconsistencies.
The System Update Readiness Tool creates a log file that captures any issues that the tool found or fixed. The log file is located at the following location:
On this Server Core, the CheckSUR.log indicated issues with two files (its an update specific MUM file with its catalog file), that the tool found to be corrupted.
Checking System Update Readiness.
Binary Version 6.1.7600.20822
Package Version 10.0
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
(f) CBS MUM Corrupt 0x00000000 servicingPackagesPackage_for_KB2207566_RTM~31bf3856ad364e35~amd64~~22.214.171.124.mum Expected file name Microsoft-Windows-ServerCore-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name
Checking Package Watchlist
Checking Component Watchlist
Checking Component Store
Seconds executed: 165
Found 1 errors
CBS MUM Corrupt Total count: 1
Unavailable repair files:
I also came across this Technet forum post, which is similar in nature but is applicable to different corrupt files with different symptoms, however it was this post that gave me the idea to fix my problem.
1. I downloaded the KB2207566 (Windows6.1-KB2207566-x64.msu) as indicated by SUR log, and copied it to Server Core (c:temp). Note that this patch already had been installed but for some reason had the mentioned files corrupted.
2. I then extracted the MSU file into a sub folder and extracted the *.cab files.
c:temp>wusa Windows6.1-KB2207566-x64.msu /extract:c:servicingkb2207566
c:tempkb982214>expand Windows6.1-KB2207566-x64.cab -F:* files
The two files I had to replace were these :
The location for the existing files that had to be replaced was c:windowsservicingpackages and an issue I ran into, as it was indicated on the Technet post (when I simply attempted to UNC and copy from another regular W2K8 machine) was that these were protected files and the copy/create option was denied. Lot of systems folders/files in Windows 7 and Windows Server 2008 have a different owner than ‘administrators’ and the TrustedInstaller is set as owner and has full control rights set.
3. And I then opted to use the command line option to take the ownership of the folder and assign ‘administrators’ the full rights on the Server Core.
takeown /f c:windowsservicingpackages /r /d y
icacls c:windowsservicingpackages /grant administrators:F /T
4. And lastly I copied the extracted files and replaced.
35~amd64~~126.96.36.199.cat? (Yes/No/All): y
1 file(s) copied.
35~amd64~~188.8.131.52.mum? (Yes/No/All): y
1 file(s) copied.
No restart was required and the DCPROMO with the answer file succeeded as it was now able to install the ADDS binaries and the DC promoted successfully.
Note that prior to the fix I also noticed that I was unable to enable the remote management from the SCONFIG (option 4, sub option 3) which also worked afterwards.