Automation issues with 1.5.19

PowerShell Universal Universal Automation
1 
Product: PowerShell Universal
Version: 1.5.19
IIS, LocalSystem AppPool

Guys, I’m out of ideas here. Decided to finally try out PowerShell Automation, but having weird issues

Issue #1:
This was on v1.5.8
Scheduled tasks were way off. For example I set 2 triggers at 7:30 AM and 6:30PM, but they ran like around seemingly random times lol.

image
image1083×478 12.3 KB

After checking changelog I noticed there was potentially a fix for this? I have since upgraded to v1.5.19 and will report back if this is still an issue

Issue #2:
Getting these in event logs. Related to issue #1 and the scheduler bug in another topic I found?

Failed to schedule job. CRON expression is invalid. Please see the inner exception for details. (Parameter ‘cronExpression’) Wrong number of parts in the 0 30 18 ? * MON-FRI * cron expression, you can only use 5 or 6 (with seconds) part-based expressions.

Issue #3:
I have no problems impersonating service accounts (domain user) from Universal Dashboard and it works great.
However same service account and same exact code will NOT run on PSU Automation using RunAs account unless I add this service user as local Administrator. So it definitely smells like permission/policy problem on my IIS/PSU server.

Script is basic on-prem exchange session that is used with invoke-command

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exchange/PowerShell/ -Authentication Kerberos
$ruleExists = Invoke-Command -ScriptBlock { Get-TransportRule “Disclaimer: xxx” } -Session $session

Service user is added to following policies at “Local Policies > User Rights Assignment”:

  • Generate security audits
  • Adjust memory quotas for aprocess
  • Replace a process level token
  • Log on as a service
  • Log on as a batch job
  • Impersonate a client after authentication

I also tried “Allow log on automatically”, “Access this computer from the network”, “obtain an impersonation token from another user…”, etc policies, but nothing worked.
However as soon as I add this service user as local Admin, script works ok.

Thoughts?

Kind regards,
Ray

2

Ok can confirm that Issue #1 is still a problem. For now PSU Automation is completely unusable for me, I’ll need to go back to Windows scheduler for time being :frowning:

image
image862×306 11.1 KB

image
image977×692 29.8 KB

3

Also weird thing about Issue #3 I have discovered.

  • Works when user is in local Administrators group
  • Stops working when taken out of Administrators group, as expected
  • Works after I initiate CMD > runas /profile /user:domain\svcaccount cmd, but stops working if I do iisreset.

It appears this issue has something to do with PSU:Automation not being able to load profile when using runas, unless target service user is made Administrator or someone loads that user’s profile manually (without admin).

4

For #1 - Can you send some logs? That’s weird that the times are so off. That said, based on the error, Hangfire (our scheduling library) does not like the CRON expression you are using. It makes me think that the issue in #2 is causing #1. Can you let me know how you generated this CRON expression? Does it work in other tools?

#3 - You are the app pool as this service account user? Or are you trying to execute a script as the service account user but running the app pool as another user?

5

Hi Adam
Thanks for the reply and apologies for late response.

I was indeed using wrong 7 variable Cron expression that also included seconds and years. From documentation I found that you suggest using simpler 5 variable expressions from crontab.guru website. That should fix problems #1 and #2

#3
Correct, app pool runs as service account (domain user), but I am trying to run Automation job as another service account (also domain user).
image

Idea is to have multiple service accounts, one for each system that follows least privilege model. Each service account is basically used for a specific task - such as creating mailboxes on Exchange, Microsoft Teams admin, Azure AD queries, etc.

This issue appears to be with apppool’s user not having enough local permissions to initially create “runas” session.
Here are my observations so far:

  • It works when apppool user is in Administrators group
  • It stops working immediately when appool user is removed from Administrators group
  • It works with appool user removed from Administrators group only if I RDP to server as myself (domain admin) and use “runas” command on target service user (that appool is trying to run as). I can then close down all cmd prompts, log out from RDP session and it will continue to work until I reboot the server.

Super weird.