At the start of 2016, I reviewed a product called Softera Adaxes, which automates user management. I’m a big fan of it, and have been continually using it since (yes I’m a paying customer!).
The more we’ve used it, the more refined my rules have been. Sometimes they need to be adjusted to cover a scenario I didn’t consider (such as, a new starter with a hyphen in their last name, but not wanting the hyphen in the username). Other times it’s been a new requirement, and a re-think on how the rules need to be modified to cover new scenarios.
How Easy Was It To Change?
I’m happy to report that these changes have been quite easy to do. You need to be careful and think about changes before you do them. One trick for testing new user creations was to not send out email alerts if a certain field had the word ‘Test’ in it, which let me test the system live without other staff getting advised. Pretty simple, but effective:
Since using it, I’ve learnt through both trial and error, as well as Softerra support, several improvements on how to manage my rules based on my personal requirements. I thought it would be a good idea to share these tips which should help both new and existing users.
One quick one that Adaxes Support on their forums helped me with, was stopping a new user creation before it started, if the username already existed. A quick ‘Before User Creation’ business rule created with this script ensures the task will bomb out with a nice message, rather than potentially making changes on an existing user that were unwanted.
For the bigger picture on how I’d designed Adaxes for new users, I’d originally created a bunch of steps in the business rules for ‘After User Creation’. I had a big runsheet of many ‘ifs’ and ‘ands’ for a new user, but then had a thought; what if I want to re-enable a disabled user? None of these rules could be applied, because they’re against a new user. I don’t want to delete and re-create the account as that causes a lot of 3rd party app issues. Adaxes Support helped me on this one again, and suggested Custom Commands instead.
Now You’re Working With Modules
The idea was to make the whole design modular. Instead of having all the steps inside the ‘After User Creation’ business rule, move each step into it’s own custom command. From there, the custom commands can be called in order from the ‘After User Creation’ business rule. This reduced the Business Rule from 40 lines down to 9:
Of course that complexity was moved to the Custom Commands, but as each grouping (e.g. Enable Email) was it’s own command, it became much cleaner and easier to read as well as manage.
After chopping up all the rules this way, I created a dummy user. I was impressed that it worked perfectly first time! (side note – when you run something via the web interface, you’ll get back a very useful report on each step that ran and any errors. This is really helpful when troubleshooting.)
My next step will be to now create a ‘modify user’ rule that is for returning staff, and will call most of these modules. The ones that don’t fit for an existing account can just be replaced by a modified custom command for what I need.
Another basic point I worked out by going through this process, is that I should be more granular in where by business rules are pointing. Originally I pointed the ‘after a user is created’ business rule at my entire AD structure. After realising that I want a different process for contractor accounts, I narrowed down the rule to only point to the OUs that normal new users would be placed in, allowing for a different set of rules when a new user is created in the contractor’s OU.
Conclusion
One of the great things about all this, is that it’s easy to change your setup. There’s no re-writing from scratch – everything can be modified, or copy/pasted to where you want it to go.
I’m still really enjoying managing and using Softerra Adaxes, often with it sitting in the background for months while other staff use it for user management; with very little room for user error.
Softera sponsored the writing of this post.