none
[PowerShell] Exchange script not running as a Scheduled Task RRS feed

  • Question

  • I have a handful of Exchange scripts that run automatically as scheduled tasks using an Active Directory service account that is a member of the Organization Management group (a default Exchange group).  I am trying to migrate these scheduled tasks (via export/import) and copied my PowerShell scripts to the same drive and folder on another server, but they do not seem to work correctly on the new server.

    When I run the scheduled tasks on the new server either manually or if they run themselves on schedule, the powershell.exe processes just takes up around 56 MB of RAM but 0% CPU utilization and sits there in that state.  After a few minutes, the RAM usage slowly starts to drop until it's a little under 2 MB of RAM.  Eventually, the scheduled tasks time out after the two hour maximum task runtime I have configured and the Task Scheduler shows the following error:  "The last run of the task was terminated by the user (0x41306)".

    Here is an example of one of my scheduled tasks that I am having trouble with on the new server:

    • Run as:  DOMAIN\ExchangeTask
    • Run whether user is logged in or not
    • Command:  %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe
    • Arguments:  -command ". 'D:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; D:\Scripts\Generate-ExchangeMailboxDetailReport.ps1"
    • Start in:  D:\Scripts
    • Start the task only if the computer is on AC power:  Disabled

    Both servers are Windows Server 2008 R2 Standard SP1.  Both are running PowerShell 2.0.  I have already configured the service account the scripts run as with the "Log on as a batch job" security right in Local Security Policy on the server and also rebooted the server.  Additionally, the service account is not restricted by which computers it is permitted to log on to in Active Directory.  I have also tried the "Run with highest privileges" option, but this made no difference.  I checked to make sure that both RemoteExchange.ps1 and Generate-ExchangeMailboxDetailReport.ps1 exist at the paths specified on the new server and they do.  I've also made sure to launch PowerShell as admin and run Set-ExecutionPolicy Bypass beforehand.

    If I launch a cmd.exe session as the DOMAIN\ExchangeTask account and then run the following command, the script runs and completes successfully in well under the two hour maximum allotted.  Additionally, the powershell.exe process running as DOMAIN\ExchangeTask quickly ramps up to around 170 MB and uses around 99% CPU the entire time it is executing.

    %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -command ". 'D:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; D:\Scripts\Generate-ExchangeMailboxDetailReport.ps1"

    This seems to tell me that there is nothing wrong with my command and argument strings nor my script, but that something else is going wrong when the Task Scheduler tries to run the task.  But I have no idea what that might be.

    Any help that could be provided on this issue would be appreciated.





    Monday, February 9, 2015 10:02 PM

Answers

  • So then, if the script works standalone, then it's not a scripting issue.

    It's going to be difficult to troubleshoot this from afar in a forum because we don't have access to the computer in question.

    If this is critical, I would suggest hiring a consultant or opening a Microsoft support ticket.


    -- Bill Stewart [Bill_Stewart]

    Friday, February 13, 2015 9:46 PM
    Moderator
  • I never called MS support about this, but one of our other sysadmins played around with it and got it to work by granting our scheduled task account the Log on locally right and adding it to the local Administrators group.  I feel like I tried both of those things, but perhaps I only tried them independently and not at the same time.

    In any case, this did resolve the issue though I don't understand the mechanism.  There is no reason I can see that it should not have worked without these two things being set.

    Wednesday, March 25, 2015 2:45 PM

All replies

  • Make sure the script runs standalone, with the needed parameters, before you attempt to schedule it.

    I would recommend placing all of the code you need in a single script and schedule that. For example:

    Command: C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe

    Parameters: -file GenerateReport.ps1

    Start in: D:\Scripts

    The content of GenerateReport.ps1 would contain:


    & "D:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1"
    Connect-ExchangeServer -auto
    D:\Scripts\Generate-ExchangeMailboxDetailReport.ps1
    


    -- Bill Stewart [Bill_Stewart]

    Monday, February 9, 2015 10:16 PM
    Moderator
  • Exchange server does not like to be connected to without a session.

    I recommend placing good debugging or tracing statements in your script and reviewing what is actually happening. YOu can try 'Start-Transcript <filepathname>"  to get full info.


    ¯\_(ツ)_/¯


    • Edited by jrv Monday, February 9, 2015 11:08 PM
    Monday, February 9, 2015 11:08 PM
  • Firstly, the script does run standalone.  The same identical task running the same identical script with the same identical command line as the same identical user account running on the same OS version and service pack level works fine on another server.  It just doesn't work on the one we are migrating to.

    If, on the new server where I am having trouble, I launch cmd.exe as DOMAIN\ExhangeTasks and then run the command...

    %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -command ". 'D:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; D:\Scripts\Generate-ExchangeMailboxDetailReport.ps1"

    ...everything works fine.  The script completes successfully relatively quickly and does what it is expected to do.  It does not work only if I run it as a scheduled task (running as DOMAIN\ExchangeTasks, the same account used to launch the cmd.exe window for the test).  When I run it as a scheduled task, the script seems to run until the time out value has passed, when it becomes "terminated by the user".

    As suggested by jrv, I put in Start-Transcript and Stop-Transcript and have figured out why the task seems to be hanging when run as a scheduled task on the new server: it gets a PSInvalidOperationException when trying to connect to each Exchange server and after it runs out of Exchange servers to try, it prompts for someone to type in the FQDN of an Exchange server.  Of course, this is impossible when running as a scheduled task as a non-logged-in user.

    I tried adding the -NonInteractive switch and this prevents the task from getting stuck waiting at a prompt, but that just makes the whole Exchange connection fail and since my script utilizes mostly Exchange-related PowerShell cmdlets, the scheduled task and script can't do much of anything and it completes unsuccessfully and the scheduled task reports an exit code of 1.

    Here is what I see in the transcript:

    **********************
    Windows PowerShell Transcript Start
    Start time: 20150213134557
    Username  : DOMAIN\ExchangeTasks
    Machine   : SCRIPTSERVER (Microsoft Windows NT 6.1.7601 Service Pack 1)
    **********************
    Transcript started, output file is D:\Scripts\_tscript.log
    
             Welcome to the Exchange Management Shell!
    
    Full list of cmdlets: Get-Command
    Only Exchange cmdlets: Get-ExCommand
    Cmdlets that match a specific string: Help *<string>*
    Get general help: Help
    Get help for a cmdlet: Help <cmdlet name> or <cmdlet name> -?
    Show quick reference guide: QuickRef
    Exchange team blog: Get-ExBlog
    Show full output for a command: <command> | Format-List
    
    Tip of the day #7:
    
    The Exchange Management Shell is a calculator too! Try it directly at a command prompt:
    
     1.2343+3123 or (23/435)*2
    
    VERBOSE: Connecting to CASSERVER1.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://casserve...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to CASSERVER2.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://casserve...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to MBSERVER1.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://mbserver...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to MBSERVER2.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://mbserver...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to CASSERVER3.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://casserve...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to MBSERVER3.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://mbserver...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    WARNING: No Exchange servers are available in the Active Directory site OTHERSITE. Connecting to an Exchange server in
    another Active Directory site.
    VERBOSE: Connecting to CASSERVER1.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://casserve...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to CASSERVER2.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://casserve...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to CASSERVER3.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://casserve...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to MBSERVER1.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://mbserver...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to MBSERVER2.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://mbserver...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    VERBOSE: Connecting to MBSERVER3.domain.com
    An internal error occurred.
        + CategoryInfo          : InvalidArgument: (http://mbserver...tVer=14.3.123.4:Uri) [], PSInvalidOperationException
        + FullyQualifiedErrorId : CreateRemoteRunspaceFailed
    
    Failed to connect to an Exchange server in the current site.
    Enter the server FQDN where you want to connect.:

    I looked into this PSInvalidOperationException and found some people experiencing a similar problem with PowerShell remoting in scheduled tasks vs an interactive session, but there didn't seem to be a solution that I could find.

    The closest I got to a solution the following thread:

    https://social.technet.microsoft.com/Forums/exchange/en-US/8c44a6bc-73b2-4c1a-a0a2-c43c3d7c9d63/2010-cmdlet-access-errors-running-as-task-under-nonprivileged-account-using-rbac?forum=exchangesvradminlegacy

    This thread talked about seeing an error "The function: RegisterGPNotification failed unexpectedly. GetLastError=-2147024882" in the "Analytic" log for Windows Remote Management.  I confirm I am seeing that error on the machine I'm having trouble with; however, in searching a solution for this I found that none of the solutions apply to me.  They all seem to have to do with a restrictive service ACE on the gpsvc (Group Policy Client) service, w3svc (World Wide Web Publishing Service) service, and SCMANAGER (?) that does not permit the account in whatever context access to those things.

    Well, I checked the ACE of all three of those things on the working server with the non-working one and they are identical, so that isn't the issue.

    Friday, February 13, 2015 9:41 PM
  • So then, if the script works standalone, then it's not a scripting issue.

    It's going to be difficult to troubleshoot this from afar in a forum because we don't have access to the computer in question.

    If this is critical, I would suggest hiring a consultant or opening a Microsoft support ticket.


    -- Bill Stewart [Bill_Stewart]

    Friday, February 13, 2015 9:46 PM
    Moderator
  • Have you tried using implicit remoting instead of attempting to load up a complete EMS shell?

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Friday, February 13, 2015 9:57 PM
    Moderator
  • Have you tried using implicit remoting instead of attempting to load up a complete EMS shell?

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Yes, and essentially the same thing happens: the attempt to establish a remote session with Exchange gets an internal error / PSInvalidOperationException.

    It's looking more and more like this is a case for Microsoft's official support.

    Friday, February 13, 2015 11:06 PM
  • The exchange remote shell is very touchy about running in a disconnected (headless?) session.  If you just out the few commands in that cause the issue then post them I will try them on my server array to see what I get.  I can do more debugging I think due to having done this a bit more.

    My sense is that it won't work but I haven't tried exactly what you are doing.


    ¯\_(ツ)_/¯

    Saturday, February 14, 2015 12:48 AM
  • Actually it looks like what I expected. It will not even connect.

    Try loading the shell manually and doing an explicit connect to see what happens.

    One thing is guarantee. You cannot do this by scheduling a remote session on a non-Exchange box. 

    I too have been waiting for MS to fix the EMS.


    ¯\_(ツ)_/¯

    Saturday, February 14, 2015 12:51 AM
  • Actually it looks like what I expected. It will not even connect.

    Try loading the shell manually and doing an explicit connect to see what happens.

    One thing is guarantee. You cannot do this by scheduling a remote session on a non-Exchange box. 

    I too have been waiting for MS to fix the EMS.


    ¯\_(ツ)_/¯

    It works fine in an interactive session, just not as a scheduled task.

    I don't agree with you that it does not work on a non-Exchange box.  Both the old and new boxes I've been referring to have only the Exchange 2010 management tools installed on them and we've been successfully scheduling various PowerShell scripts that leverage EMS cmdlets since 2011 on the old box.  In fact, we've been using the exact same scripts, script and executable paths, command line arguments, user account, and task settings.

    Pretty much everything is the exact same.  I don't understand why it doesn't work. Like I said, we will have to call Microsoft.

    Tuesday, February 17, 2015 4:54 PM
  • I never called MS support about this, but one of our other sysadmins played around with it and got it to work by granting our scheduled task account the Log on locally right and adding it to the local Administrators group.  I feel like I tried both of those things, but perhaps I only tried them independently and not at the same time.

    In any case, this did resolve the issue though I don't understand the mechanism.  There is no reason I can see that it should not have worked without these two things being set.

    Wednesday, March 25, 2015 2:45 PM