I'm trying to dynamically leverage the currently connected domain controller by using the environment variable $env:LOGONSERVER.
More specifically like
$DomainController = ($env:LOGONSERVER).Replace("\\", "")
That works in every powershell scenario except when I compile it as a Windows Service. At that point it returns a NULL value. Windows event logs as well as my own transcript logs show it happening as such. Am I missing something?
Side note: I don't want to use the command get-addomaincontroller because I want this to be able to run on any machine of my choosing w/o the need for AD PS Module.
Environment variables not recognized when compiled
Forum rules
Do not post any licensing information in this forum.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
Do not post any licensing information in this forum.
Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
-
- Posts: 7
- Last visit: Wed Nov 02, 2022 12:09 pm
Re: Environment variables not recognized when compiled
Your code is just wrong both syntactically and logically.
Here are valid methods:
Here are valid methods:
Code: Select all
$domainController = $env:LOGONSERVER -replace '\\\\'
$domainController = $env:LOGONSERVER -replace '\\+'
$domainController = $env:LOGONSERVER.Replace( '\','')
-
- Posts: 7
- Last visit: Wed Nov 02, 2022 12:09 pm
Re: Environment variables not recognized when compiled
Thanks for the suggestion but none of the three versions you provided worked. They all returned the same error as my version. "Cannot validate argument on parameter 'ComputerName'. The argument is null or empty".
Can you explain why my method was syntactically wrong when it worked in every powershell scenario besides being compiled as a service?
Just to add, if I even try doing something as simple as write-host "Test $env:logonserver" I get no data in the variable and get the output "Test ".
I guess I can provide more context as to the command I'm trying to run
Can you explain why my method was syntactically wrong when it worked in every powershell scenario besides being compiled as a service?
Just to add, if I even try doing something as simple as write-host "Test $env:logonserver" I get no data in the variable and get the output "Test ".
I guess I can provide more context as to the command I'm trying to run
- $domainController = $env:LOGONSERVER.Replace( '\','')
- invoke-command -computername $domainController -scriptblock {[extra code here]}
Re: Environment variables not recognized when compiled
Then you environment variable is empty. You will need to discover why.
Use a message box to display the contents of the variable. When running as a service there is no Logon variable. Service run under the system account and the system is not logged onto anything. It is joined. Try running the service under a full domain user account.
Use a message box to display the contents of the variable. When running as a service there is no Logon variable. Service run under the system account and the system is not logged onto anything. It is joined. Try running the service under a full domain user account.
-
- Posts: 7
- Last visit: Wed Nov 02, 2022 12:09 pm
Re: Environment variables not recognized when compiled
I could kind of understand that may be the cause because the service was running under system but after changing the service to run under a domain account, it still could not pull that environment variable. I decided to abandon the dynamic method for now and just leverage the config file by having the domain controller specified in that. It's going to be a server application with proper ntfs permissions applied so I'm not worried about specific things being in the config file.
Thanks for the assistance.
Thanks for the assistance.
Re: Environment variables not recognized when compiled
You will have issues if the profile is not loaded by the service.
It is also a very bad idea to specify a server for a command. If the logon server is an RODC or is unavailable then the command will fail. Let windows find a server automatically. It will always pick the best DC for the command and will resolve all issues.
It is also a very bad idea to specify a server for a command. If the logon server is an RODC or is unavailable then the command will fail. Let windows find a server automatically. It will always pick the best DC for the command and will resolve all issues.