
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2020 03:34 PM
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!
Solved! Go to Solution.
- Labels:
-
Discovery
-
Orchestration (ITOM)

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2020 03:56 PM
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2020 03:35 PM
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2020 05:18 PM
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-01-2020 12:42 AM
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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-18-2020 03:56 PM
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