Best Practice for "Domain Controller" Variable in AD Orchestration

joegarcia
Kilo Expert

Hey all,

We're configuring some Orchestration activities with the goal of automating user account creation. When using the Active Directory Activities, the activities require the IP address of a domain controller instead of using a hostname such as example.domaincontroller.com . Our systems team is fully against using the same IP address every time since we have multiple domain controllers that replicate. If one of them goes down and we're using that specific DC's IP address, we'll run into issues where the automation would fail. Do you all have any recommendations on best practices for this example? Would a round-robin dns entry that we resolve using the "Resolve DNS Name" activity be sufficient? Same goes for the Exchange Orchestration Activities we want to configure: we have multiple exchange servers that replicate and always connecting to one of them could possibly cause some issues.

Any guidance would be greatly appreciated. We would prefer to use best practices defined by ServiceNow. Please let me know if you need any more information or if this post should be moved to a different community. Thanks!

1 ACCEPTED SOLUTION

Perhaps you could add Resolve DNS capability to your activity and check. But interestingly I have it working without that capability. Do you have Discovery module in your instance?


View solution in original post

7 REPLIES 7

VivekSattanatha
Mega Sage
Mega Sage

Hi Joseph,



We are running AD activities/Exchange activities without using IP address.   We pass FQDN value from System property. We have created custom system property for our AD and Exchange servers. When Orchestration runs we pass the system property value to scratchpad variable. This is the best workaround if you want to change your AD or Exchange server you just have to change your system property, you do not have to change the hostname or IP address in the activity all the time.



In your run script, you need to pass the value like this



workflow.scratchpad.adserver = gs.getProperty('primary.ad.server');



primary.ad.server' property will have the value of AD Server FQDN and workflow.scratchad.adserver will go to as a target host in all All AD activities inside the workflow.



Regards,


Vivek



Based on the impact hit like, helpful or correct


Hey Vivek,



Thanks for the info. I thought we could use the FQDN, however, when I use that in the activity it always returns this error (even after pulling the FQDN from a system property):





Using the IP address works just fine as all AD activities execute successfully, and the documentation on docs.servicenow.com states to use an IP address, so I assumed it had to be an IP address and not an FQDN. Is there something else I may be missing?


Sorry, it looks like the picture from my last comment didn't go through. Here's the picture of the error.


eccerror.png


Perhaps you could add Resolve DNS capability to your activity and check. But interestingly I have it working without that capability. Do you have Discovery module in your instance?