Using the Active Directory module - assistance required
I note the format of the script during one of the webinars (39:56) remotes to the DC. As we do not have remote PS rights to our DCs, I can't figure out how else to make this work.
The error we get when we try using $env:COMPUTERNAME in place of the $DC variable is:
Unable to contact the server. This may be because this server does not exist, it is currently down, or it does not have the Active Directory Web Services running.
Of course, I have installed AD Web Services on this machine and it works perfectly well using PowerShell ISE.
The original runbook had encrypted credentials and remoted to another server using credssp, but using certs to encrypt our credentials is a bit of a pain.
How can I get this script to work in CPA?
Leigh_Kilday Member Ninja IT Monkey ✭✭✭✭Hi @Brian_Wiest, I was just using that as an example since my network is disconnected and I can't get my scripts up here.
I'm using SMA for this so it's no longer an issue.0
I Always execute remote AD command using the following method:
Just make sure the AD CMDLet is installed on the workflow server then.
Also make sure that the SCSM Workflow account has the rigths to perform the task you want to perform in the script.
Hope it helps
Did you make any progress with this? I think Filip's suggestion is interesting and seems promising, although I haven't tried it personally.
One other suggestion I have when it comes to PS remoting might be to use a PSSession against a custom PSSessionConfiguration. With typical installations, you have a few PS Session Configurations by default (view these with Get-PSSessionConfiguration as an admin). You can create new session configurations, and for these custom sessions you can limit the cmdlets available to users of that session. For example, if you only wanted those users to use the "Get-ADUser" cmdlet when they connect, you could do that. Further, for each session, you can configure only certain users to be able to connect (i.e. the workflow service which is running CPA).
One other note is that we don't need to connect to the DC, and I would recommend against that anyway since it seems to be an unnecessary risk. Any machine with the AD Cmdlets installed should be able to use this method, and it keeps an extra bit of distance between DC and automation tools/users.
This has become so second nature to me I actually assumed I'd have to perform the same thing in a Cireson PSA. But again, haven't tested this.
Installing Remote administrator tools on your primary SCSM server will add AD locally so you can just run the command on the local server.
(Screenshot from Server 2008)
I'm using SMA for this so it's no longer an issue.