Hi there,
I've created a script that I'm trying to use as part of a VM deployment. The simplified version of the script is that I'm attempting to have the computer joined to the domain. I'm using the Add-Computer cmdlet and I've been able to manually run the script successfully from the command prompt and everything executes correctly. The problem I'm running into is that the script is executing as Local System since I'm adding the script into the local group policy in Computer Configuration/Windows Settings/Scripts/Startup to have the script launch. Now I had a different script that doesn't do the domain join (Add-Computer) and it executes that way with no issue. It appears that the issue is due to the fact that the user context when this script executes through the local group policy is under the SYSTEM user. I can recreate the issue for debugging purposes by setting up a scheduled task to run the script and select the SYSTEM account to run the task as. So I'm trying to understand and resolve the issue, which raises two questions for me:
1. Why is the SYSTEM account not able to execute the Add-Computer cmdlet and how do I see what's actually happening or why it's happening? The script does start but never finishes, and I end up having to terminate with task manager.
2. How do I deal with this? The solution I'm trying to get working is to use Invoke-Command to launch a new session under a different user context. Would this be the best approach? I've now run into the same issue which appears to be from when Local System is trying to create a New-PSSession object. This code again just stalls at this point and never continues to run.
My code is listed below that I'm debugging with. Can anyone shed some light into how to deal with the user context issue or get additional debugging information?
Thanks
$logfile = "c:\scripts\contextlog.txt"
If ((Test-Path $logfile) -ne $true) {
New-Item -Path $logfile -type file -value "Initializing file"
}
$testblock = {
Param($u1, $p1, $logtest)
Add-Content $logtest "`nAccount details are $u1 with password $p1"
Add-Content $logtest "`nCodeblock executing as $env:userdomain\$env:username"
Write-Host "This is inside the code block running under the security context $env:userdomain\$env:username" -f Green;
}
$joinAcct = "MYDOMAIN\admin"
$joinPW = "DOMAINPASSWORD"
$localacct = "admin"
$localpass = cat c:\scripts\adminpw.txt | ConvertTo-SecureString
$LocalCred = New-Object -typename System.Management.Automation.PSCredential -ArgumentList $localacct, $localpass
Add-Content $logfile "`nCreating Remote Session"
$localSession = New-PSSession -Credential $LocalCred
Add-Content $logfile "`nRemote session for user context change"
Invoke-Command -Session $localSession -ScriptBlock $testblock -ArgumentList $joinAcct,$joinPW,$logfile
I've created a script that I'm trying to use as part of a VM deployment. The simplified version of the script is that I'm attempting to have the computer joined to the domain. I'm using the Add-Computer cmdlet and I've been able to manually run the script successfully from the command prompt and everything executes correctly. The problem I'm running into is that the script is executing as Local System since I'm adding the script into the local group policy in Computer Configuration/Windows Settings/Scripts/Startup to have the script launch. Now I had a different script that doesn't do the domain join (Add-Computer) and it executes that way with no issue. It appears that the issue is due to the fact that the user context when this script executes through the local group policy is under the SYSTEM user. I can recreate the issue for debugging purposes by setting up a scheduled task to run the script and select the SYSTEM account to run the task as. So I'm trying to understand and resolve the issue, which raises two questions for me:
1. Why is the SYSTEM account not able to execute the Add-Computer cmdlet and how do I see what's actually happening or why it's happening? The script does start but never finishes, and I end up having to terminate with task manager.
2. How do I deal with this? The solution I'm trying to get working is to use Invoke-Command to launch a new session under a different user context. Would this be the best approach? I've now run into the same issue which appears to be from when Local System is trying to create a New-PSSession object. This code again just stalls at this point and never continues to run.
My code is listed below that I'm debugging with. Can anyone shed some light into how to deal with the user context issue or get additional debugging information?
Thanks
$logfile = "c:\scripts\contextlog.txt"
If ((Test-Path $logfile) -ne $true) {
New-Item -Path $logfile -type file -value "Initializing file"
}
$testblock = {
Param($u1, $p1, $logtest)
Add-Content $logtest "`nAccount details are $u1 with password $p1"
Add-Content $logtest "`nCodeblock executing as $env:userdomain\$env:username"
Write-Host "This is inside the code block running under the security context $env:userdomain\$env:username" -f Green;
}
$joinAcct = "MYDOMAIN\admin"
$joinPW = "DOMAINPASSWORD"
$localacct = "admin"
$localpass = cat c:\scripts\adminpw.txt | ConvertTo-SecureString
$LocalCred = New-Object -typename System.Management.Automation.PSCredential -ArgumentList $localacct, $localpass
Add-Content $logfile "`nCreating Remote Session"
$localSession = New-PSSession -Credential $LocalCred
Add-Content $logfile "`nRemote session for user context change"
Invoke-Command -Session $localSession -ScriptBlock $testblock -ArgumentList $joinAcct,$joinPW,$logfile