- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-13-2014 08:23 PM
Anyone try using the new Password Reset application in Dublin / Eureka? I was wondering how easy it is to integrate with AD. How long did it take to get up and running? Pros? Cons? Any hidden issues?
I'm also wondering if the "Password Reset - Orchestration Add-on" requires the Orchestration plugin as well. I would assume so, the wiki does not explicitly say so, but I don't like to assume anything with SN licensing anymore.
Thanks
Jim
Solved! Go to Solution.
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-19-2014 01:30 PM
One of the challenges we found with the AD Password Reset is that, using the built-in ServiceNow workflow items, the account needed to be a Domain Administrator (which our AD Team would not allow). We ended up having to develop our own powershell command to do the password reset on the MID Server, rather than using the SN way of calling out to the DC. Not hard, but frustrating. It appears that those who do Discovery had the same sort of issues when I did a search at the time.
You can do the AD Password Reset without Orchestration as far as I recall when you write your own commands to work with the Powershell probe on the MID Server. We had to do this and I seem to recall thinking that it is a loophole or something, because you can write everything through the MID Server without much trouble.
One other thing we also found is that the ServiceNow SMS feature did not text to phone number, it texted to 11122233333@att.com, and thus required the carrier information to be present. We ended up just coding a call to Twilio, which was easy enough, and it handles the text to phone number (as our phone numbers sync from an external system).
We really found it was shoe-horning ServiceNow into a world where we could perform the tasks we need much better without ServiceNow (we need to share data with ERPs), and just use a web service to feed the data into ServiceNow about what is being done (failed attempts, successful attempts, etc). I also seem to recall that SN had a Password Reset app (above and beyond Orchestration) but you paid a monthly fee for each user in your system, and with 180,000+ users, that was not going to work too well for us.
I am using words like "I recall" and a lot of past tense because we are going a different route for password reset. But I have it all developed (without the use of Orchestration workflow items even though we have Orchestration) and such in our instance to demo the functionality of it.
Oh - I should also state I have only used this in Dublin/Calgary, not Eureka. We do not have that loaded yet.
Hopefully that helps. As you can tell, sometimes I ramble on too much.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-16-2014 08:40 AM
We went the route of developing a custom web app that deals with the password reset. This seemed to provide us a lot more flexibility than going the ServiceNow route, and quite frankly, cost us very little to develop and virtually nothing to maintain. We sync well over 100,000 AD Accounts with SN, and paying on a per-account basis is very difficult (when considering the SN built and supported offerings).
Our web app will feed the reset attempts (both successful and unsuccessful) into ServiceNow where we can do processing on the information for creating calls (in the conditions we want them) and alerting IT Security when an odd situation is encountered. This limits the information that is stored on the web server, while allowing us to do statistics, metrics, watch for strange events (certain IP address resetting multiple user passwords) and so on.
From a user perspective, the web app will ask for certain information they know which is in our ERPs (DOB, etc) and if correct send a PIN to them via SMS, Email or Voice (based on our records). Once they enter the PIN they can reset their AD password. I think the activities are pretty much the same as SN and other big players (google, microsoft, etc).
We have virtually the exact same functionality developed within ServiceNow using Powershell scripts run off the MID Server (our AD Admins would not create an account with Domain Admin permissions to use the AD Orchestration activites, and they could not find any other permission set to communicate with the DC) so I think it was a pretty fair comparison when the decision was being made by our management as to which route to go (using SN professional services to develop what we needed, us developing what was needed 100% in SN, us developing outside of SN).
If you have any other questions I would be happy to answer!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-17-2014 07:57 PM
Thanks for the detailed response Trevor - Very helpful. I should have noted why I am interested - Password Reset is one of the products I'm now responsible for so I may take you up on your offer! Thanks again!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-24-2014 11:07 PM
Hi Trevor,
The information was very useful.
Will you please tell us how to run Powershell scripts off the Midserver (without enabling Orchestration).
From the various articles I went through, it is mentioned that running Powershell scripts off Midserver is not possible without enabling Orchestration.
Regards,
Shyama
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-25-2014 08:42 AM
It has been awhile since I went through all this, so forgive the foggy details or if something in the product/licensing has changed.
The MID Server allows you to have Powershell capabilities, without Discovery or Orchestration. Once you enable these capabilities you are able to submit commands directly to the ecc_queue that tell it to use your MID Server and it's Powershell capabilities. You then take this a step further and use it to allow you to run Powershell scripts (which you can also pass in variables to) because the MID Server will run it (provided it has the appropriate Powershell version, modules, etc) as you have enabled the capabilities of Powershell on it. From my reading of the forums, the MID Server is far and away one of the most powerful and most underutilized features of ServiceNow when it comes to connecting with external systems and performing things like integrations.
The advantage to having Orchestration is that you are able to take advantage of their customized and predefined AD activities that use Powershell scripts (which in our instance would not work since we needed Domain Admin I was told by our AD guys when I had them troubleshoot it not working). We have Orchestration, and while handy, is not necessarily needed to run the Powershell scripts if you have the knowledge to do the development yourself. We do not really use our Orchestration piece (it was bought specifically for Password Reset), but provided you are willing to use the MID Server and develop your own Powershell scripts to interact with the probe, I fail to see what you could NOT achieve with just a MID Server. That is, until having a MID Server is something you need a license for.
I just checked on the SN Demo servers and it looks like adding the Powershell capability is there (as we probably had Orchestration licensed when I went through this), and I do not think they put Orchestration on those demo servers so I think you should be safe to enable the capability and get scripting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-08-2014 10:29 PM
Hi Trevor,
Thank You for your reply.
Will you please assist me in enabling the Powershell capabilities of the Midserver and running the powershell scripts ?
I would request you to help me with an example if possible...
Waiting for your reply...
Thanks in advance !
Regards,
Shyama