locked
Backup-GPO cmdlet errors in Task Scheduler RRS feed

  • Question

  • I have scheduled a simple script on my Windows Server 2012 domain controller to backup my group policies (separate from the System State backup). I ran the script manually, and it works as expected. I scheduled the script in Task Scheduler using a service acct with domain admin privileges. Due to our domain policy settings, I had to select the "Do not store password" option on the job, otherwise the usual error regarding "no session" is presented. This means I have access to local resources only (on the DC).

    I also right-clicked the job and selected "run" and the job executes properly. However, when the job kicked off at the scheduled time on its own, it only ran partially. The date stamped backup folder was created, and it contained a partial "manifest.xml" file which is created at every backup. The manifest only has the header in it, no other content such as GPO names and GUIDs.

    In the Powershell transcript output, it generates an error when the Backup-GPO cmdlet runs:

    Backup-Gpo : The system cannot open the device or file specified. (Exception from HRESULT: 0x8007006E)

    The command is:

    Backup-Gpo -All -Path $backup_dir\$date_stamp

    And yes, I have selected to run the job without the user being logged in. Is it possible to backup domain GPOs without the credentials cached in the job? Are the GPOs considered a "local resource" on the domain controller?

    Wednesday, January 8, 2014 4:11 PM

Answers

  • You should probably create a credential and store it in a variable, then call Invoke-command  { Backup-Gpo -All -Path $backup_dir\$date_stamp } -credential $yourcustomcredential

    the credential should have read rights in the GPO Container and read-write rights on the target folder.

    Monday, January 13, 2014 8:12 PM

All replies

  • Hi JMBartlett,

    Based on my research, when check the "Do not store password", the session will be terminated if the service account is log off, and the powershell cmdlet will fail to run.

    How about Disable the group policy: Network access: Do not allow storage of passwords and credentials for network authentication, then uncheck the "Do not store password" and have a try.

    For more detailed information, please refer to this article:

    Task Scheduler Error “A specified logon session does not exist”:

    http://blogs.technet.com/b/askperf/archive/2012/04/18/task-scheduler-error-a-specified-logon-session-does-not-exist.aspx

    I hope this helps.

    • Edited by AnnaWY Thursday, January 9, 2014 8:41 AM
    Thursday, January 9, 2014 8:39 AM
  • Anna,

    You are correct, if I disable that policy setting that I do not need to select "Do not store password" and the job runs fine.

    However, the PowerShell script does run with the "Do not store password" option checked, it just normally fails when trying to access the policies to backup with a seemingly random error depending on the domain controller.  Then, after 3 days of failures, I checked this morning and it had run fine on two of three domain controllers. No changes to policy or the script or the job. It isn't cut and dried as to why it works or doesn't work.

    I guess what I am ultimately looking for is a better description of what resources are still available using that setting ("Do not store password"); are ADDS related commands considered local resources on domain controllers, or do you always need a cached credential?

    Jim

    Thursday, January 9, 2014 7:37 PM
  • You should probably create a credential and store it in a variable, then call Invoke-command  { Backup-Gpo -All -Path $backup_dir\$date_stamp } -credential $yourcustomcredential

    the credential should have read rights in the GPO Container and read-write rights on the target folder.

    Monday, January 13, 2014 8:12 PM