- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-04-2025 06:35 AM - edited 08-04-2025 06:36 AM
Hello,
We are using azure cloud discovery to discover azure CI. We setup cloud admin portal for the instances, and run the classic discovery for the server.
I notice 2 issues :
1. There's no relation between the instance and the server.
2. Some fields on server, as the "object_id" are not filled. Looking on the discovery log, I notice on stage"43.2.2 Put script checking if this server is running on Azure", that file "confirmAzureVM.ps1" is not put on the host. Result is "succeeded", but file location is empty.
Any ideas on what could occurs ?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2025 06:31 AM
Hi @b_atrice lapeyr ,
As per my understanding problem summary of the Issues:
1. No relationship between Azure instance and discovered server.
2. Some attributes like object_id are not populated.
3. Stage 43.2.2 says confirmAzureVM.ps1 was successfully transferred, but scriptPath is empty, causing the check to be skipped.
Root Cause:
From the log:
Step condition is false. Step not executed. False Condition(s): [(${scriptPath} : value=) IS NOT EMPTY ]
This indicates that the script file was intended to be placed, but the path wasn't correctly stored in ${scriptPath}. As a result, the follow-up script execution step was skipped.
Without executing ConfirmAzureVM.ps1, the system:
* Cannot validate if the server is running on Azure.
* Fails to fetch Azure-specific metadata (like object_id).
* Cannot establish the CI relationship between the on-prem Windows server and its cloud instance in Azure.
Solution:
Step 1: Check MID Server File Permissions
Ensure that the MID Server has permissions to:
* Write to the Windows target path: C:\ServiceNow\agent\bin\sw_wmi\bin\ConfirmAzureVM.ps1
* Create and return the path for the script
Also ensure:
* The folder exists on the target machine.
* The MID Server is running with elevated privileges if necessary.
Step 2: Verify the Pattern Logic
Check the pattern associated with this discovery (usually in Cloud > Patterns for Azure):
* Go to the step Put script checking if this server is running on Azure
* Confirm that scriptPath is set as an output variable from the "Put file" step. If not, Discovery won’t populate it for the next step.
Step 3: Confirm Azure VM Identification Script
The ConfirmAzureVM.ps1 script checks for Azure metadata on the instance.
* Manually check that this script exists on the MID server in:
ServiceNow\agent\bin\sw_wmi\bin\ConfirmAzureVM.ps1
* You can test running the script manually on a discovered Windows host to ensure it returns metadata correctly (like instance ID).
Step 4: Discovery Schedule Best Practice
* Run Cloud Discovery first to populate virtual machines from Azure.
* Then run IP-based Discovery (classic) to populate OS-level CIs.
* Enable “Reconciliation Rules” to merge or relate both CIs correctly.
Step 5: Enable Cloud Linking
In Cloud Admin Portal config, ensure the "Enable instance/server relationship" setting is turned ON. This allows:
* CI from classic discovery to link with the virtual instance from cloud discovery using fields like object_id, correlation_id, or instance ID.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2025 06:31 AM
Hi @b_atrice lapeyr ,
As per my understanding problem summary of the Issues:
1. No relationship between Azure instance and discovered server.
2. Some attributes like object_id are not populated.
3. Stage 43.2.2 says confirmAzureVM.ps1 was successfully transferred, but scriptPath is empty, causing the check to be skipped.
Root Cause:
From the log:
Step condition is false. Step not executed. False Condition(s): [(${scriptPath} : value=) IS NOT EMPTY ]
This indicates that the script file was intended to be placed, but the path wasn't correctly stored in ${scriptPath}. As a result, the follow-up script execution step was skipped.
Without executing ConfirmAzureVM.ps1, the system:
* Cannot validate if the server is running on Azure.
* Fails to fetch Azure-specific metadata (like object_id).
* Cannot establish the CI relationship between the on-prem Windows server and its cloud instance in Azure.
Solution:
Step 1: Check MID Server File Permissions
Ensure that the MID Server has permissions to:
* Write to the Windows target path: C:\ServiceNow\agent\bin\sw_wmi\bin\ConfirmAzureVM.ps1
* Create and return the path for the script
Also ensure:
* The folder exists on the target machine.
* The MID Server is running with elevated privileges if necessary.
Step 2: Verify the Pattern Logic
Check the pattern associated with this discovery (usually in Cloud > Patterns for Azure):
* Go to the step Put script checking if this server is running on Azure
* Confirm that scriptPath is set as an output variable from the "Put file" step. If not, Discovery won’t populate it for the next step.
Step 3: Confirm Azure VM Identification Script
The ConfirmAzureVM.ps1 script checks for Azure metadata on the instance.
* Manually check that this script exists on the MID server in:
ServiceNow\agent\bin\sw_wmi\bin\ConfirmAzureVM.ps1
* You can test running the script manually on a discovered Windows host to ensure it returns metadata correctly (like instance ID).
Step 4: Discovery Schedule Best Practice
* Run Cloud Discovery first to populate virtual machines from Azure.
* Then run IP-based Discovery (classic) to populate OS-level CIs.
* Enable “Reconciliation Rules” to merge or relate both CIs correctly.
Step 5: Enable Cloud Linking
In Cloud Admin Portal config, ensure the "Enable instance/server relationship" setting is turned ON. This allows:
* CI from classic discovery to link with the virtual instance from cloud discovery using fields like object_id, correlation_id, or instance ID.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-05-2025 09:02 AM
Thank you for you help and all these informations. We had permission issue.