Powershell Set-ADUser doesn't run in scheduled task

Question

I finally finished a script that I was writing, which among other things, get's a list of AD users and exports to CSV, emails multiple people with specific chunks of that information, and then modifies the notes on the user account. The script works perfectly when I run it in the ISE, no problems at all.

When I try to run it as a scheduled task, everything works except for the set-aduser command. The CSV export is generated, any other errors are captured in my logging, emails are sent, but set-aduser just doesn't seem to run. I've been unable to capture any error or output, just that when I go to look at the AD account, the notes aren't updated. Again, when I run it in the ISE, it works fine. I stepped through every section of my code, and it hits set-aduser and sets the notes in the ISE. I don't think that it's an issue with my script because of this, but I've copied a generic block below. My catch block never catches anything, even if I add in -erroraction stop.

$errorlog = 'c:\Error.txt'
$file = Import-csv 'c:\Test.csv'
$errordate = get-date
foreach ($name in $file)
    {
    $newnotes = "$($name.notes) `r`n NewNotesHere" 
    $NotesUserName = $name.sAMAccountName
        try
        {
        ##Set the notes for the user
        set-aduser -Identity $NotesUserName -Replace @{info="$newnotes"} 
        } 
        catch
        {
        ##Non terminating catch, used only for error logging.
        $ErrorName = $Error[0].exception.GetType().fullname 
        $ErrorDescription = $Error[0].exception.Message 
        $ErrorLineNumber = $Error[0].InvocationInfo.ScriptLineNumber
        $ErrorOffsetLineNumber = $Error[0].InvocationInfo.OffsetInLine
        Write-host "Something went wrong setting the notes for $NotesUserName... `r`n $ErrorName `r`n $ErrorDescription  `r`n $ErrorLineNumber -- $ErrorOffsetLineNumber `r`n`r`n" -foregroundcolor Yellow
        "$errordate `r`n Something went wrong setting the notes for: `r`n $($name.firstname) $($name.lastname) -- Username: $($name.username)... `r`n $ErrorName `r`n $ErrorDescription `r`n `r`n" | Out-file -filepath $ErrorLog -append
        }
    }

The scheduled task is running on a Windows Server 2012 R2 machine, with a Domain Admin account (the same account I use to successfully test it in ISE) and formatted as below:

The only difference that I can see between running it in the ISE and running it as a scheduled task is the fact that it is a scheduled task.

I think that my biggest question is: Is there some sort of control on scheduled tasks that would stop PowerShell from modifying Active Directory?

Second Question: Whether or not there is a block, does anybody have a suggestion on how to correct this behavior?

Answer 1

In your case, I can see that you have not mentioned the execution policy . That could be one of the issues. Try bypassing that like mentioned below.

Try running the script from cmd prompt directly and see the result. These are the options . just hit powershell /?

PowerShell[.exe] [-PSConsoleFile <file> | -Version <version>]
    [-NoLogo] [-NoExit] [-Sta] [-Mta] [-NoProfile] [-NonInteractive]
    [-InputFormat {Text | XML}] [-OutputFormat {Text | XML}]
    [-WindowStyle <style>] [-EncodedCommand <Base64EncodedCommand>]
    [-ConfigurationName <string>]
    [-File <filePath> <args>] [-ExecutionPolicy <ExecutionPolicy>]
    [-Command { - | <script-block> [-args <arg-array>]
                  | <string> [<CommandParameters>] } ] 

Few major observations which I had faced:

1) Instead of giving only powershell.exe , try giving the full PS path C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe

2) Permission is one more concern. The user through which you are running the task might not have the permission to run that.

3) Execution Policy-- Make sure you are bypassing the execution policy using -executionpolicy bypass

4) Make sure you are running the task with Highest Privileges

5)Finally,through analysis of logs

Hope it helps.

Answer 2

Turns out that it wasn't a PowerShell issue at all, we were having Domain Controller issues. So it was updating, but nothing was replicating so when pulling the user account, it looked like it wasn't updated.