mid.powershell.target_base_dir - Has anyone used it?

Jaskaran Walia
Kilo Guru

Hi,

We have a challenge where our windows admin team is not happy to give us admin privileges for Domain controllers for discovery purpose. Now that we have upgraded to Orlando, i found out we can use property called "mid.powershell.target_base_dir" to set the directory to a temp folder instead of Admin$ that needs admin privileges.

I am going to play around with this property and use it but thought will ask around if anyone has used it with success to save time. Here is my approach and i will post how it goes later on.

1) Set up a temp folder on the DC host machine by working with Windows admin team.

2) Ask windows admin to get us user and password for the user with non-administrative persmission so that we can add that to SN credentials table.

3) Set MID server property mid.powershell.target_base_dir to point to new temp share folder created in step 1.

4) Run discovery and see how it goes!

1 ACCEPTED SOLUTION

Part 2:

I just wanted to share with you where we are now after raising HI ticket and trying out few more things.

HI Ticket:

Windows Discovery is writing to C:\Temp (\\<server>\C$\Temp) temporarily during Discovery, need to know if this default location can be modify with alternative pat.

So the support team did the investigation and find out that there are 2 mid server script files that have c:\temp hard coded!

Navigate to -> MID Server -> Script Files -> Then search for

WMIFileOperations.psm1

WinRMFileOperations.psm1

Need to change c:\temp in the above scripts to other accessible folders.

Testing after changing the above:

So we went ahead and changed the "C:\temp" to "C:\SNITOM\Temp"

So, when we ran discovery using admin privilege, it no long write those temp file to C:\temp but unfortunately, when we ran discovery using non-admin privilege, it failed with same message as before "Failed to launch process powershell -ExecutionPolicy ByPass -NonInteractive -WindowStyle Hidden -command "& {mode...."

So, it appears that you would still require “Admin” credentials to accessADMIN$/C$/D$/E$.

 

Other options:

1) we convince our Windows team to grant us "admin" cred and limit when we can run discovery for DC i.e. one hour daily or weekly. Also, if possible automate the grant of admin priviledge for that one hour only and rotate the password every time.

Lastly, We are thinking of exploring JEA functionality that was released as part of Orlando but SN Support team confirmed they have given skeleton scripts only and customers would have to develop their own to discovery DC.

If anyone has any luck with this, I would be keen to understand it.

 

Thanks,

Jaskaran Walia

View solution in original post

9 REPLIES 9

Jaskaran Walia
Kilo Guru

Here is the doc site link in case anyone need to read the doc site:

https://docs.servicenow.com/bundle/orlando-it-operations-management/page/product/discovery/reference/r_DiscoWinProbesAndPermissions.html

Jaskaran Walia
Kilo Guru

Here is the update after couple of hours of giving it a go.

1) I created new property for mid server:

mid.powershell.target_base_dir

value: SNITOM$

MId Server: assigned it to one MID Server.

 

Here is our findings:

When we ran using windows cred that had admin privilege:

Although discovery ran as actual cred has admin access but we have problem i.e. behaviour is script is trying to connect to \\server\C$\Temp location and then our new share \\server\SNITOM$ as we see files being written to both locations when using "Admin" credentials.

When we ran using windows cred that had non-admin privilege:


In a delegated model without "admin" credentials the \\server\C$ is blocked so it fails before getting started
There is some hard coded C$\Temp I believe in their scripts as it is not fully respecting the new "share" we created and Orlando update feature.

 

Error we got was:

Failed to launch process powershell -ExecutionPolicy ByPass -NonInteractive -WindowStyle Hidden -command "& {mode con lines=1 cols=32766; Set-Variable -Name 'SNC_isWmi' -Value $true -Scope Global; function printValues{Process{foreach-object{if($_.Properties){$a=$_.Properties}else{$a=$_.PsObject.Properties}foreach($p in $a){$o=$p.Name+' : ';if ($p.Value -is [Array]){$o+=[string]::Join(',', $p.Value);}else{$o+=$p.Value;}$o;if($p.Value -is [System.Management.ManagementBaseObject] -or $p.Value -is [System.Management.ManagementBaseObject[]]){'_EXTENDED_START:';$p.Value|printValues;'_EXTENDED_END!';}}}}}gwmi -namespace root/MSCluster MSCluster_Cluster -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_ClusterToResource -EA SilentlyContinue|select __CLASS,GroupComponent,PartComponent|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_ClusterToNode -EA SilentlyContinue|select __CLASS,Antecedent,Dependent|printValues|format-list;gwmi -namespace root/virtualization/v2 Msvm_ComputerSystem -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;gwmi -namespace root/virtualization Msvm_ComputerSystem -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_Resource -EA SilentlyContinue|select __CLASS,PrivateProperties,Name,Type|printValues|format-list;gwmi -namespace root\cimv2 Win32_ComputerSystem -EA SilentlyContinue|select __CLASS,Domain,Name|printValues|format-list;gwmi -namespace root\cimv2 Win32_OperatingSystem -EA SilentlyContinue|select __CLASS,Caption,Version|printValues|format-list;gwmi -namespace root/MSCluster MSCluster_Node -EA SilentlyContinue|select __CLASS,Name|printValues|format-list;'---SNC-SEPERATOR---REGISTRY-SECTION---';Get-ItemProperty -Path 'HKLM:/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters' -EA SilentlyContinue|select PSPath,Domain,Hostname|format-list;}" with error System.Management.ManagementBaseObject

 

Next action:

I am going to raise HI and see if they can help us.

Hi,


There is a powershell module on MID Server folder on your machine. You can check that how powershell -ExecutionPolicy this is used. But this will impact overall discovery as well be sure when you change this.

We usually manually upload domain controllers as it is sensitive to get admin rights on them

Now in orlando we have a concept of JEA but it wont work for domain controllers.


Thanks,
Ashutosh

Part 2:

I just wanted to share with you where we are now after raising HI ticket and trying out few more things.

HI Ticket:

Windows Discovery is writing to C:\Temp (\\<server>\C$\Temp) temporarily during Discovery, need to know if this default location can be modify with alternative pat.

So the support team did the investigation and find out that there are 2 mid server script files that have c:\temp hard coded!

Navigate to -> MID Server -> Script Files -> Then search for

WMIFileOperations.psm1

WinRMFileOperations.psm1

Need to change c:\temp in the above scripts to other accessible folders.

Testing after changing the above:

So we went ahead and changed the "C:\temp" to "C:\SNITOM\Temp"

So, when we ran discovery using admin privilege, it no long write those temp file to C:\temp but unfortunately, when we ran discovery using non-admin privilege, it failed with same message as before "Failed to launch process powershell -ExecutionPolicy ByPass -NonInteractive -WindowStyle Hidden -command "& {mode...."

So, it appears that you would still require “Admin” credentials to accessADMIN$/C$/D$/E$.

 

Other options:

1) we convince our Windows team to grant us "admin" cred and limit when we can run discovery for DC i.e. one hour daily or weekly. Also, if possible automate the grant of admin priviledge for that one hour only and rotate the password every time.

Lastly, We are thinking of exploring JEA functionality that was released as part of Orlando but SN Support team confirmed they have given skeleton scripts only and customers would have to develop their own to discovery DC.

If anyone has any luck with this, I would be keen to understand it.

 

Thanks,

Jaskaran Walia