I have just been following this guide for restoring AD user objects but I’m just a little unclear with how the $Computer and $Credential variables are defined within the ‘User Restore.ps1’ script?
Also, I assume I need to import the Active Directory Module? I am currently doing that manually within the -Content block of the page (not sure if that is correct) or if there is a preferred/more effective way of loading modules?
I have manually specified the server name for the -Server parameter in the $DeletedUsers variable which works and it populates the columns with all the deleted objects, however, the job fails to restore the user and I think it might be to do with the ‘Restore User.ps1’ script. I have tried to manually specify the parameters in the ‘Restore User.ps1’ script but having no luck.
Assuming you have already installed the RSAT AD tools then you probably dont need to import the module (depending on the server version you are using) but it wont hurt.
Second if your are running PU not under iis its running as a service, what account is that service running under? It might not have permissions to perform the restore of a user.
I am not sure on this but you might want to specify an ID with the Invoke-UAScript, then when you do a get-udjob you can look for the id you created. Right now it looks like you are using $job as the ID but that is not set anywhere. so its Null.
Is the Job created in the admin portal under jobs?
What is being accepted for the -DistinguishedName param? Is it, $DistinguishedName as per the script in the UA Admin Console or is it $Item.DistinguishedName that is defined in the Table above?
The distinguished name is being passed from that table as a param to the script. The computer name and credential variables are defined globally in the Automation \ Variables configuration.
There is an undocumented option I need to include in the docs called -GrantAppToken. It can be set on New-PSUDashboard in dashboards.ps1. It will automatically grant and app token if the user does not have one and connect the dashboard to the PSU API so you shouldn’t have to call Connect-UAServer\Connect-PSUServer.
Otherwise, you will have to call Connect-PSUServer with an app token of your choosing even though it’s in the same server.
The reason we did it that way was that we wanted to track the user that was actually accessing the API from the dashboard but it might have made things a bit too complex by default.