Azure AD join error code 8018000a

No Gravatar

Recently when attempting to perform an Azure AD Join with a Windows 10 v1511 computer I got the following error:

Something went wrong.  The device is already enrolled.  You can contact your system administrator with the error code 8018000a.

image

That didn’t make sense because I had recently disjoined the computer from Azure AD.  I could find no reference to the object in the Azure portal either.

A Bingoogle search yielded only one relevant result… the ConfigMgr client is installed.

https://osddeployment.wordpress.com/2016/02/27/azure-ad-join-error-code-8018000a by Per Larsen [MVP].

I knew this wasn’t the case.  So… read the error again.  “the device is already enrolled”.  Checking Settings -> Accounts -> Work Access revealed the obvious: the computer was still being managed via OMA-DM (Intune), but associated with a different user.

image

Ok.  Log off, then back on as the other administrator account.

Navigate back to Work Access and sure enough, the MDM enrollment was there.  Un-enroll and bingo, Azure AD Join worked!

image

image

August 27, 2016

Posted In: Microsoft Azure

Tags:

Recovering from BCD error 0xC000000D with BitLocker and Hyper-V

No Gravatar

I recently had a nasty issue with my seriously awesome laptop (Lenovo ThinkPad P50 with a Samsung 950 Pro NVMe n.2 SSD).  After a full shutdown (hold Shift when shutting down Windows 10) on the next power on I got a BitLocker recovery prompt.

That’s happened before, so I just powered off and back on like I’ve always done.  However, this time I was greeted with a foreboding BCD error:

image

I pulled out my handy-dandy USB drive that just happened to still be configured as boot media for Windows 10 v1511 and used the F12 boot selection to boot to it.  When prompted to install Windows, instead I typed Shift+F10 to get a command prompt.

I ran the following commands to confirm that the SSD did still exist.

All seemed fine there.

Time to rebuild the BCD… so I ran the following to scan for the instance of Windows

Hmm… no Windows OS found.  Ah, BitLocker is enabled.  Of course BootRec can find anything.  Let’s unlock the drive with the following commands:

Great!  Let’s try BootRec again:

Time to see if it worked… reboot… success!  Windows loaded right up.  Awesome, I’m back in business.

I decided to suspend BitLocker on my Windows partition for now just to be safe.  I’ll re-enable it after I’m sure everything is working.

Now let’s get back to work… booting up my ConfigMgr lab…

Doh!  The VM guest failed to start because the hypervisor is not running.

image

Checking Services confirmed that the HV Host Service was stopped but still set to Automatic.  Attempting to start the service threw another error:

Windows could not start the HV Host Service service on Local Computer.  Error 31: A device attached to the system is not functioning.

image

That’s right… I destroyed the Hypervisor configuration in BCD.  Let’s go fix that:

P.S.  PowerShell doesn’t like the ‘{current}’ syntax so I used a standard Administrative Command Prompt

BCD configuration before and after the change:

image image

The home stretch…

Reboot again and Hyper-V is now running my VM lab!  Whew.  That’s wasn’t much fun!

 

Thanks to a few blogs and forum posts that helped out a ton.

http://www.sevenforums.com/hardware-devices/82226-boot-bcd-0xc000000d-unreadable-boot-configuration-data.html

https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/01/19/hyper-v-virtual-machines-do-not-start-after-using-startup-repair/

http://blogs.interfacett.com/enabling-hypervisor-auto-start-boot-configuration-database-bcd

http://superuser.com/questions/858259/hyper-v-reports-that-the-hypervisor-is-not-running-how-to-start-the-hypervisor

August 12, 2016

Posted In: Windows 10

Using a Task Sequence Secret Value when changing a local password

No Gravatar

At one time it became routine to manage Windows local account passwords with a Group Policy Preference.  However, some time ago the process was was discovered to have a significant venerability and Microsoft released security bulletin MS14-025 to address the issue.  But Microsoft didn’t fix the vulnerability.  Instead they removed the ability for GPP to save user names and passwords in Local Users and Groups, Drive Maps, Scheduled Tasks, Services, and Data Sources.

There are many options to handle managing local account passwords including:

  • MS14-025 includes a lengthy PowerShell script which will reach-out to remote computers to change the password and log the change in a central text file
  • Microsoft Local Administrator Password Solution (LAPS) is a great free solution which should be seriously considered
  • ConfigMgr (SCCM / Microsoft System Center Configuration Manager) deployment
  • a dozen other options not listed here

While discussing the ConfigMgr options with a few colleagues we came up with the following:

  • Application or Package deployment with a script which has an embedded password or uses a password formula / calculation
  • A Compliance Setting and Baseline with a script a script which has an embedded password or uses a password formula / calculation
  • A Task Sequence deployment with a script which has an embedded password

I’ve created a Compliance Setting and Baseline for a customer in a situation where they had ConfigMgr clients on workgroups and joined to domains which they could not manage.  This worked really well for them.  The embedded script used a simple Base64 conversion to obfuscate the password and the password was not exposed on the command line, but there was no actual encryption.

Turning to the Task Sequence discussion option, a suggestion was made to call NET USER from a Run Command action.  This sounded easy.  Too easy.  Besides, wouldn’t the command including the password be exposed in SMSTS.log?  Not if a “Secret Value” Task Sequence Variable is used!

Follow these steps in configuring a Task Sequence:

Set a Task Sequence Variable named “ADMPW” or similar, enter the clear text value, then enable the “Secret value” check box.

Select OK to save/close the variable properties, then look at it again and notice that the value is quite different than what you’ve typed.  It’s encrypted!

image

Now, call the NET USER command line with the variable

NET USER administrator %ADMPW%

image

Reviewing the SMSTS.log helps validate that the password is not exposed.

image

The log only shows “Action command line: smsswd.exe /run: net user administrator %ADMPW%”

The ConfigMgr Task Sequence using a “Secret Value” Variable can be an effective method of changing local account password.

June 21, 2016

Posted In: ConfigMgr 2012

Tags: ,

ConfigMgr fails to distribute a package… failed to create instance of IRdcLibrary

No Gravatar

Awhile back I had an issue distributing a new Package in ConfigMgr (SCCM).  There didn’t seem to be anything unique about the package, it just didn’t want to process.  Digging into the SMS Distribution Manager log (distmgr.log), I noticed a number of errors about the file not being found, couldn’t be added, can’t create a snapshot,etc.  The IRdcLibrary keyword is the real clue.

After reinstalling the Windows feature Remote Differential Compression, Distribution Manager started working again.

Start adding package P010017D...
The Package Action is 2, the Update Mask is 268435456 and UpdateMaskEx is 0.
CDistributionSrcSQL::UpdateAvailableVersion PackageID=P010017D, Version=1, Status=2300
Taking package snapshot for package P010017D from source \\CM01\PackageSource\updates\2016\\CM01\PackageSource\updates\2016
failed to create instance of IRdcLibrary    SMS_DISTRIBUTION_MANAGER
CreateRdcSignature failed; 0x80040154   SMS_DISTRIBUTION_MANAGER
CreateSignature failed    SMS_DISTRIBUTION_MANAGER
CreateRdcFileSignatureW failed; 0x80040154        SMS_DISTRIBUTION_MANAGER
CFileLibrary::AddFile failed; 0x80040154  SMS_DISTRIBUTION_MANAGER
CFileLibrary::AddFile failed; 0x80040154  SMS_DISTRIBUTION_MANAGER
CContentDefinition::AddFile failed; 0x80040154   SMS_DISTRIBUTION_MANAGER
Failed to add the file. Please check if this file exists. Error 0x80040154               SMS_DISTRIBUTION_MANAGER
SnapshotPackage() failed. Error = 0x80040154      SMS_DISTRIBUTION_MANAGER
STATMSG: ID=2361 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=CM01.ad.contoso.com SITE=P01 PID=6244 TID=4488 GMTDATE=Fri Apr 15 14:06:24.604 2016 ISTR0="\\CM01\PackageSource\updates\2016" ISTR1="Test" ISTR2="P010017D" ISTR3="30" ISTR4="22" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="P010017D"         SMS_DISTRIBUTION_MANAGER  4/15/2016 9:06:24 AM    4488 (0x1188)
Failed to take snapshot of package P010017D
       SMS_DISTRIBUTION_MANAGER
CDistributionSrcSQL::UpdateAvailableVersion PackageID=P010017D, Version=1, Status=2302
STATMSG: ID=2302 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=CM01.ad.contoso.com SITE=P01 PID=6244 TID=4488 GMTDATE=Fri Apr 15 14:06:24.616 2016 ISTR0="Test" ISTR1="P010017D" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="P010017D"         SMS_DISTRIBUTION_MANAGER  4/15/2016 9:06:24 AM    4488 (0x1188)
Failed to process package P010017D after 3 retries, will retry 22 more times
Exiting package processing thread.            SMS_DISTRIBUTION_MANAGER

June 20, 2016

Posted In: ConfigMgr 2012

Tags: ,

SSRS Error 401.3 Access is denied

No Gravatar

So, you’ve been denied!  It’s OK.  It happens to the best of us.

If you are lucky enough be gifted with this message take a look at the NTFS rights of the SQL Server Reporting Services instance which will likely be a folder like C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services.  Granting the appropriate AD group read & execute rights may solve the problem.

clip_image002

Server Error in ‘/Reports’ Application.

Access is denied.

Description: An error occurred while accessing the resources required to serve this request.  You might not have permission to view the requested resources.

Error message 401.3: You do not have permission to view this directory or page using the credentials you supplied (access denied due to Access Control Lists).  Ask the Web server’s administrator to give you access.

Thanks to Mike and Jerry for pointing me in the right direction.  After carefully reading the error, it is quite obvious isn’t it.

http://stackoverflow.com/questions/17685452/ssrs-401-3-error-access-denied-due-to-access-control-lists

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/747f9846-dd9a-4fb4-914a-283871d6cedf/client-failing-to-access-the-ssrs-2008-sp1-report-manager-url-with-access-denied-error-4013?forum=sqlreportingservices

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/fd41a86b-976f-4851-8dae-5561ebc6d719/browse-reportserver-return-4013-error-after-joined-domain?forum=sqlreportingservices

June 20, 2016

Posted In: SQL Reporting

Tags: , , ,

Downgrading SQL from Enterprise Edition to Standard for ConfigMgr

No Gravatar

At a recent client engagement we discovered that Microsoft SQL Server Enterprise edition was installed on the ConfigMgr Primary Site Server.  Technically this is not a problem, but it is only needed if you expect to have more than 50,000 clients*.  As this environment wasn’t anywhere close to the limit so there was no need to pay the extra licensing cost of Enterprise edition (Standard edition comes with the ConfigMgr licenses).

 

These steps are largely based on the Jonathan Kehayias approach as documented by Brady Upton at MSSQLTips.

Steps for SQL Enterprise to Standard downgrade

  • On each database verify that no Enterprise features are utilized (SELECT * FROM sys.dm_db_persisted_sku_features)

select ‘Master’ as [Database], * from [master].[sys].[dm_db_persisted_sku_features]

select ‘Model’ as [Database], * from Model.[sys].[dm_db_persisted_sku_features]

select ‘msdb’ as [Database], * from msdb.[sys].[dm_db_persisted_sku_features]

select ‘tempdb’ as [Database], * from tempdb.[sys].[dm_db_persisted_sku_features]

select ‘CM_P01’ as [Database], * from CM_P01.[sys].[dm_db_persisted_sku_features]

select ‘SUSDB’ as [Database], * from SUSDB.[sys].[dm_db_persisted_sku_features]

select ‘ReportServer’ as [Database], * from ReportServer.[sys].[dm_db_persisted_sku_features]

select ‘ReportServerTempDB’ as [Database], * from ReportServerTempDB.[sys].[dm_db_persisted_sku_features]

  • Document databases, security, maintenance plans, and jobs
  • Verify the SQL version number and ensure install files are available (SELECT @@VERSION)
  • Stop and disable backup software
  • Stop ConfigMgr, IIS, and Windows Update services (set to disabled if desired)
  • Backup databases (system and user)
  • Stop SQL services
  • Copy the master, model and msdb database files (.mdf and .ldf) to another location
  • Uninstall SQL Enterprise instance (all features)
    • The Shared tools do not have to be uninstalled; however, if they are not then reporting the SQL edition in the future will be confusing
  • Reboot
  • Install new SQL Standard instance as required by ConfigMgr being sure to keep the same instance name and file/folder paths.
    • Review the Required and Optional configurations for SQL server (64-bit, SQL_Latin1_General_CP1_CI_AS, Database Engine, Windows Authentication, min/max Memory, nested triggers, CLR integration, static TCP ports, etc.)
    • If the original SQL ConfigurationFile.ini is still around, installing based on this file can make all of the configurations fool proof.
  • Patch SQL to the same version as before
  • Verify the SQL version and edition (SELECT @@VERSION)
  • Stop SQL Server and copy/restore the system databases
  • Configure Trace flags (see section below)
  • Start SQL server and verify databases, security, and jobs are as before
    • If login fails, use PSEXEC to start SQL Management Studio as the SYSTEM account, then recreate any SQL Logins needed
  • Enable common language runtime (CLR) integration (sp_configure ‘clr enabled’,1; reconfigure)
  • Enable and start IIS, and Windows Update services… verify WSUS is working
  • Enable and start ConfigMgr services
  • Verify event Viewer and ConfigMgr logs and monitoring to ensure ConfigMgr is healthy
  • Re-enable and start backup software

 

 

SQL Trace Logs

Using this method is simple and easy, but there is one additional thing to keep in mind… SQL Trace flags (thanks Allen for pointing this out).  When installing SQL, trace flags are not enabled / added by default; this is taken care of by the ConfigMgr installation.  Since we are not doing a ConfigMgr installation or a site reset, etc. these options need to be added manually.

  • Open SQL Server Configuration Manager
  • Navigate to SQL Server Services -> SQL Server… -> Properties
  • Add "-T8295"
  • Add "-T4199"
  • Apply, stand on one foot, OK, Close

image

Executing DBCC TRACEON (4199,-1) and DBCC TRACEON (8295,-1) in SQL Server Management Studio will enable these flags as seen by executing DBCC TRACESTATUS (-1).  However, this only affects the current session and they need to be added as startup flags.

 

SQL and ConfigMgr References

Additional / Related References

April 20, 2016

Posted In: Uncategorized

ConfigMgr Status Message Viewer MFC120u.dll Missing Error

No Gravatar

 

When the ConfigMgr Admin Console version 2012 SP2 (or 2012 R2 SP1) is installed and the ConfigMgr client is not updated on the same computer you could see an error like the one below.

image

statview.exe – System Error

The program can’t start because mfc12u.dll is missing from your computer. Try reinstalling the program to fix this problem.

 

StatView is the utility that displays ConfigMgr status messages and is typically initiated from the console by navigating to

  • Monitoring \ Overview\ System Status \ Site Status
  • OR Monitoring \ Overview\ System Status \ Status Message Queries

StatView.exe requires Microsoft Visual C++ and ConfigMgr 2012 SP2 now uses VC++ 2013 which is not installed as part of the Console.

 

To resolve the issue, install Microsoft Visual C++ 2013 Redistributable (x86) which can be found at \client\i386\vcredist_x86.exe">\client\i386\vcredist_x86.exe">\\PrimarySiteServer\SMS_<SiteCode>\client\i386\vcredist_x86.exe.  Notice that the x86 version is required even if you are running Windows x64.  This is because StatView is a 32-bit application.

image

This will install and register mfc12u.dll and other files which should resolve the issue.

 

You can verify the installation in Programs and Features (Add/Remove Programs) as shown below.

image

Microsoft Visual C++ Redistributable (x86)…

 

Problem. Solved.

September 24, 2015

Posted In: Uncategorized

Tags:

ConfigMgr Reporting Services Point with complex SQL

No Gravatar

In a new ConfigMgr 2012 R2 SP1 environment the Reporting Services point was proving a bit challenging to install.  After setting all of the required permission it was finally happy. 

Required Permissions

On the SQL Server Reporting Services server, an account (in this case a domain user "functional" or "service" account) needed the following:

  • Membership in the server’s local Administrators group
  • SSRS Site Settings -> System Administrator, System User
  • SSRS Folder Settings on the root folder -> Browser, Content Manager, My Reports, Publisher, Report Builder

Scenario Details

This ConfigMgr environment has a complex configuration with 3 different SQL servers in play.

  • Server1: ConfigMgr Primary Site server
  • Server2: server running SQL Server Database Engine role and configured as the ConfigMgr Site Database server
  • Server3: server running SQL Server Reporting Services role
  • Server4: server running SQL Server Database Engine role with only the ReportServer database

With Server1 (ConfigMgr) and Server2 (SQL DB) configured and most functionality working (software deployment, software update deployment, OS deployment, inventory, etc.) it was time to install Reporting Services point.  We created a new ConfigMgr Site Server for Server3 using a domain user account.  However, when attempting to install the Reporting Services point the following error was encountered:

image

  • Unable to locate any configured SRS instances on the server.  Verify SRS is installed, accessible, and correctly configured.
  • The "Reporting Services server instance" is blank.

 

We knew that SSRS was installed, configured, and working as there were two other applications already using the SRS instance in a production capacity.

We verified the domain user account could actually access the SSRS website from Server1 (the ConfigMgr server) and discovered

  • the account was a member of the local Administrators group
  • the account had System Administrator rights to the SSRS Site
  • the account could not see any existing reports or report folders and the following message displayed: "User ‘<domain>\<userID>’ does not have required permissions.  Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed."

As the screen shot shows, UAC was actually disabled already.

image

Once the domain user account was given rights to the root folder, the Reporting Services point role could see the Reporting Services server instance the the role installed without issue.

image

After the role installed, ConfigMgr reset its own permissions to give the domain user account only "ConfigMgr Report Users, ConfigMgr report Administrators" roles.

image

Also, the logs for the Reporting Services point are on the SSRS server (Server3 in this case), and located at C:\SMS\logs

August 27, 2015

Posted In: Uncategorized

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

 

Additionally, after installation was successful, it was not possible to mount a WIM or create boot media in ConfigMgr.

Crating ConfigMgr or MDT Task Sequence Media fails with the error:

Error: 1313  A required privilege is not held by the client.  Refer to CreateTsMedia.log file to find more details.

image

CreateTSMedia.log file…

using CreateMedia.exe /K: boot … fails

 image

The PowerShell cmdlet New-CMTaskSequenceMedia -BootableMedia … fails

Mounting a WIM with DISM fails

image

DISM.exe /Mount-Image /ImageFile: …

Error: 1313  A required privilege is not held by the client.

Solution

In my case the root cause was that a default permission was removed for the local Administrators group by a domain policy.  

image

By default, the User Right Assignment for "Back up files and directories" and "Restore files and directories" is held by the "Administrators, Backup Operators".  But in this case the "Administrators" group had been removed and replaced by the "Domain Admins". 

Since my account isn’t and shouldn’t be a domain admin, I simply added it to the local "Backup Operators" group, logged off, logged back on, and presto!  Success.

Workaround

If the User Right Assignment isn’t you issue, another solution, or rather workaround, is 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.

 

Other instances and workarounds

There are a few instances of the same error documented in a few blogs and forum posts.  The options basically include ensuring you are running as an administrator (and with the administrator token), running as SYSTEM (as described in my workaround), or dis-joining the computer from the domain and running as admin.

August 21, 2015

Posted In: Uncategorized

Tags: , , ,

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