none
Add-KdsRootKey failing with "The process cannot access the file..."

    Question

  • Hello community,

    Environment
    Mixed with one (1) domain controller running Windows Server 2008 and one (1) domain controller running Windows Server 2012.

    Steps to Produce the Problem
    These steps produce the problem both on the Windows Server 2012 domain controller and on another Windows Server 2012 server configured for centralized management. I login with my account which is in the Domain Admins group, and I start the Active Directory Module for Windows PowerShell with Administrative privileges. I execute the Import-Module Kds command; then I execute the Add-KdsRootKey -EffectiveImmediately command and get the following error:

    Other thoughts
    Based on my understanding of the elements at work here, I believe there is a file located on the domain controller itself that is being locked by some other service. If anyone could provide clues as to which file and/or service could be at fault, I'd appreciate. Alternative theories are more than welcome.

    Thanks in advance,
    Michael

    Tuesday, November 19, 2013 9:26 PM

Answers

  • Had the exact same issue.

    After hours and hours of digging through logs and looking to see what the command was doing we managed to fix this.

    This process only looks for its Domain Controllers in 1 place, the Domain Controllers Container !!

    So if like us you manage an enterprise that has quite a lot of DC's and you split them out into Sub OU's of the DC container, this will fail :(Simply ensure that you have a DC running the relevant OS in the root of the Domain Controllers container while you run this command, and that's a slightly odd hurdle overcome.

    Hope this solves the issue for some people

    Monday, April 07, 2014 2:34 PM

All replies

  • It's not recommended to reboot a DC in production for troubleshooting (is this production?), but you could try to reboot the server and then see if the command works (to clear out any locked files).

    You could also use sysinternals to monitor the files in use at the time of running this cmdlet.

    Lastly, you could try the command without the argument. 

    You can also try logging in and out again, in case of an expired password for the logged-in account.

    Does the server have AV configured?

    Not seen this before, and I ran this cmdlet myself earlier with no issues?



    • Edited by GSS1 Wednesday, November 20, 2013 4:54 PM
    Wednesday, November 20, 2013 4:46 PM
  • Thanks for the reply. I've tried rebooting, but it made no difference. I've actually also tried the command without an argument, but it produces the same error. I've logged in and out as part of the rebooting process, and my password definitely isn't expired.

    Thanks for trying. I'm the sort who will move heaven and earth before I will post a question on a forum, so I'm in pretty deep with this one.

    Wednesday, November 20, 2013 4:58 PM
  • Hmm I thought the server was maybe pending a reboot.

    What about AV? Is that configured on the server?

    Sysinternals seems like a good option right now. Anything further in the event log?

    The other thing I am wondering is that gMSA seems to be introduced in 2008 R2 and not 2008, so I am wondering if that is an issue here as you mentioned one DC is 2008 but the problem seems to be isolated to the 2012 DC obviously.

    What management tools do you have on the server - re monitoring, backups, etc? This may be interfering with the ability for the DC to operate.


    • Edited by GSS1 Wednesday, November 20, 2013 5:50 PM
    Wednesday, November 20, 2013 5:50 PM
  • According to the documentation: "Managed Service Accounts (and Virtual Computer Accounts) apply to both Windows Server 2008 R2 and Windows Server 2012. Group Managed Service Accounts can only be configured and administered on computers running Windows Server 2012 but can be deployed as a single service identity solution in domains that still have some DCs running operating systems earlier than Windows Server 2012. There are no domain or forest functional level requirements."

    http://technet.microsoft.com/en-us/library/hh831782.aspx

    I will check on those other things and let you know.

    Wednesday, November 20, 2013 6:01 PM
  • Sounds like a plan. 

    If all is fine in that area, I'd advise you to check AV and the other suggestions. Maybe there is a more serious, underlying issue with AD and a health-check is called for.

    Wednesday, November 20, 2013 6:03 PM
  • Hi Michael,

    Do you have any progresses on this issue?

    Please let us know the latest situation, so we could help you solve this issue efficiently.

    Best Regards,

    Amy Wang


    Friday, November 22, 2013 3:22 AM
    Moderator
  • I haven't had a lot of time to work on it, but here is what I've tried.

    I completely removed the anti-virus software and isolated the server to strictly the AD DS role and the File Server role (used only for SYSVOL and NETLOGON) without success. There is no more software to be removed, but the problem persists. I'm not entirely sure what to look for with sysinternals, and this is the output from dcdiag:

    Does anyone have any insight at all as to what file is being accessed by the Add-KdsRootKey cmdlet? I know the file referenced in the error is not the Microsoft.KeyDistributionService.cmdlet.dll because I can still execute Get-KdsRootKey without error (it's blank, by the way).

    Friday, November 22, 2013 5:02 PM
  • Hi Michael,

    According to the DCDiag results, there isn’t any specific error. It seems like that the Domain Controller is healthy.

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Best Regards,

    Amy Wang

    Monday, November 25, 2013 7:36 AM
    Moderator
  • Thank you.
    Monday, November 25, 2013 6:52 PM
  • Hi Michael,

    I recommend you to use Process Monitor tool to find out which process is using KDS root key.

    Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity.

    Here are some introduction links below about Process Monitor:

    Process Monitor v3.05

    http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

    Monitor Process

    http://technet.microsoft.com/en-us/library/hh206046.aspx

    Happy Thanksgiving Day!

    Amy Wang

    Thursday, November 28, 2013 3:25 AM
    Moderator
  • I've already been using Process Monitor, but I have no idea what file I'm looking for. As far as I can tell, KDS root key isn't a file.
    Thursday, November 28, 2013 3:36 AM
  • Hi Michael,

    Sorry about my mistake.

    I have installed Process Monitor on my machine, and used powershell to test this command.

    Since it’s not a Domain Controller, so this command failed.

    Anyway, I suggest you focus on the Query Directory part of powershell.exe to locate the file.

    Best Regards,

    Amy Wang

    Thursday, November 28, 2013 7:52 AM
    Moderator
  • The only thing that was recorded when I issued the command was that powershell.exe went on the hunt for PSConsoleHostReadLine in a variety of locations and with a variety of extensions.
    Thursday, November 28, 2013 11:49 PM
  • Please try to execute the Add-KdsRootKey -EffectiveImmediately command on the DC 2008 and verify if it can be added successfully. Thanks.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, December 04, 2013 12:34 PM
  • The KDS PowerShell Module didn't come into existence until Windows Server 2012. That cmdlet is not available on the Windows Server 2008 DC. Is there something I need to install to make it available?
    Wednesday, December 04, 2013 7:13 PM
  • Please run that common on the DC at the restore mode and check if it works.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, December 06, 2013 12:15 PM
  • Common? Restore mode? I don't understand what you're saying.
    Thursday, December 12, 2013 6:01 PM
  • run that command on the DC at the restore mode.

    Restart your computer, and then press and hold F8 during the initial startup to start your computer in restore mode.

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, December 13, 2013 5:16 AM
  • I booted into Directory Services Restore Mode, which I had to research separately, but I don't see a way to run PowerShell. The command prompt option is the classic DOS-style shell, and issuing the command "PowerShell" turns up nothing. I can't actually run this command without PowerShell.
    Friday, December 13, 2013 5:35 AM
  • Did you find a solution to your problem? I am having a similar issue.

    Thanks


    ***** This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, February 27, 2014 1:35 PM
  • Did you find a solution to your problem? I am having a similar issue.

    Thanks


    ***** This posting is provided "AS IS" with no warranties, and confers no rights.

    What os are you on?

    Do you have AV on the server?

    To all - have you tried ta tool to identify locked files and the owning processes?
    • Edited by GSS1 Thursday, February 27, 2014 3:20 PM
    Thursday, February 27, 2014 3:19 PM
  • Never mind. The problem in my case was that I was trying to do it in one of the child domains. The account that I was using was part of the Domain Admins for that domain; but, I guess it need it to be part of the Enterprise Admins as well.

    After adding the account to the Enterprise Admins and running the command again it worked.

    http://technet.microsoft.com/en-us/library/jj128430.aspx
    "Membership in the Domain Admins or Enterprise Admins groups, or equivalent, is the minimum required to complete this procedure"

    I guess they do not mention anything about child domains.


    ***** This posting is provided "AS IS" with no warranties, and confers no rights.


    • Edited by Tony Mex Thursday, February 27, 2014 3:46 PM
    Thursday, February 27, 2014 3:45 PM
  • Had the exact same issue.

    After hours and hours of digging through logs and looking to see what the command was doing we managed to fix this.

    This process only looks for its Domain Controllers in 1 place, the Domain Controllers Container !!

    So if like us you manage an enterprise that has quite a lot of DC's and you split them out into Sub OU's of the DC container, this will fail :(Simply ensure that you have a DC running the relevant OS in the root of the Domain Controllers container while you run this command, and that's a slightly odd hurdle overcome.

    Hope this solves the issue for some people

    Monday, April 07, 2014 2:34 PM
  • Son of a bi** was going nuts on this one!  Move the DC to the root of DC and worked like a charm! 
    Friday, April 11, 2014 5:38 PM
  • I had actually given up on this, but I checked and my domain controller was in a sub-folder. I moved it to the root, and tried the command again. By God, it worked!
    Friday, April 11, 2014 7:27 PM
  • dang man.  I never would have figured that out.  Thanks a ton for this.  
    Thursday, June 04, 2015 2:31 PM
  • We've recently come across customers experiencing failure to start the KDS service, and determined that it was because their DC's were in sub-OUs, not the top-level Domain Controllers OU.

    Happened across this thread while researching the issue , and see last several responses.

    Glad to see you got it working.    The subOU thing makes perfect sense.

    Shortly there will be a hotfix published to allow this command to work even if DC is in a subOU.

    I'll follow up on this thread when that takes place.


    • Edited by tfair - MSFT Thursday, September 03, 2015 8:37 PM
    Thursday, September 03, 2015 8:34 PM
  • The problem described in this thread is now resolved via an officially released hotfix at this URL:

    https://support.microsoft.com/en-us/kb/3094486

    Thanks for your patience while this issue has been under investigation!

    Wednesday, October 21, 2015 12:39 PM