Welcome to Adaxes. In this video we’ll be looking at automation
of user lifecycle processes, such as onboarding, offboarding as well as other management activities
in AD, Exchange and Office 365. Why is this important? Well, automating such tasks can save a significant
chunk of administrative resources, which would otherwise get spent on manually executing
them, simplify user management procedures and make them more robust and reliable by
eliminating the type of human-factor errors that are simply inevitable with manual management. The way automation works in Adaxes is by using
Business Rules, which enable the automatic execution of sets of actions either before
or after certain events in AD. So, let’s start with the onboarding of new
users and see how Adaxes can be configured to automate all the procedures associated
with this. As I said, to automate this process we need a Business Rule, which we already have set up here. And, as you can see, it is set to be triggered every time a new user account is created in Active Directory, which is when the provisioning
procedures need to happen. Once a new account is created, Adaxes will
automatically execute all the onboarding actions that are listed in the rule. So, let’s have a closer look at them. First Adaxes will create and share a home
folder for the new user. As you can see, to make the home folder’s
path unique, it uses value references, which will be substituted with the user’s department
and username, and it will also give the user full control rights for the folder. After that Adaxes will create an Exchange
mailbox for the user. If you have multiple mailbox databases, you can set up how mailboxes should be distributed across them. Adaxes can either automatically use the least occupied DB out of the ones that I select in the list or use the round robin method
for them. After the mailbox is created, Adaxes will
configure it. It can set up various parameters of the mailbox,
such as storage quotas, mailbox rights, policies, mailbox features and so on. For example, in this particular case Adaxes
will automatically enable Archiving for the mailbox. Note that in this example we’re creating
and configuring an on-prem mailbox, but Adaxes can also fully provision a mailbox in Exchange
Online as a part of our user onboarding procedures, using exactly the same approach. After it’s done with the mailbox, Adaxes
will then activate an account in Office 365 for the user and assign licenses. If I need to, I can break it down to assigning
only individual services within the license. And, for example, if I need more control over
this particular action, I could allow Adaxes to execute it only after the operation has
been approved, by, for example, the user’s manager. And same thing can also be applied to any
other action in the Business Rule. Also, I can set certain actions to be executed
only if they meet some conditions. For example, I can set Adaxes to activate
an Office 365 account and assign licenses only if the user I’m creating is not a subcontractor,
by simply using a corresponding condition that will check that the user’s Employee
Type does not equal ‘Subcontractor’ before activating an Office 365 account. And I could use the same approach, for example,
to assign different licenses depending on the user’s job title, department or in fact
any other criteria. Using conditions allows me to implement all sorts of complex business logic for onboarding procedures and provision different user accounts in different ways, according to the specific requirements of the users, effectively letting Adaxes take the context of the operation into account. Coming back to our rule, after it’s done
with Office 365, Adaxes will then set various parameters of the user account in AD, for
example, here it puts a record of who provisioned the user account and when into the Notes property
and configures Remote Desktop Settings for the user; and in a similar fashion, it could
set any other property. If I need Adaxes to do something else to provision
a new user account, I can simply add other actions to the list, like enabling the user
for Skype for Business, granting rights for the mailbox to the new user’s manager, sending
the initial password to the user through SMS, sending a welcome email with initial instructions, notifying the manager about a new arrival and so on. However, if the provided actions aren’t
enough and I want to include some custom scenarios as part of the automation process, Adaxes
allows me to use PowerShell scripts for that. For example, here I have a script that adds
a new record for the new user to my local database, and it’s executed just like any
other action. Also, if I know that the script will take
a long time to run, I can set it to be executed asynchronously, so that it won’t hold up
all the other actions in the Business Rule. Finally, I have two other actions that execute
two Custom Commands - ‘Update Location’ and ‘Update Group Membership’. Each of these commands contains its own set
of actions and conditions. For example, ‘Update Location’ moves users
to OUs based on their ‘City’ property. So, if the new user’s city is set to New
York, it will move the user to the ‘New York Office’ OU, if it’s London — to
the ‘London Office’ OU and so on. The ‘Update Group Membership’ command adds users to groups that correspond to their department and removes them from any department
groups they don’t belong to. Now we’ve got the Business Rule for user
onboarding all set up, let’s switch to Adaxes Web Interface to actually create a new user
in AD to see how it all works. To do that, first I need to fill in all the
details for the new hire on the user creation form. Note that I’ve configured fields like ‘City’
and ‘Department’ to be required, as my automated workflows rely on their values;
and also note that both of them have drop-downs, so I can only select one of the predefined
values. Finally, let’s give the new user a manager
and call it a day. And once I click the Finish button, Adaxes
will then create a user account in AD and automatically execute all the provisioning
procedures. So, once the new user is created, we can see straight away that the account was moved to the correct OU which corresponds to the City I’ve specified, a home folder was created with a unique path, the user was added to
a group associated with the Sales department, a mailbox was created and configured, including enabling Archiving that we’ve set back in the rule, an Office 365 account was activated
and a correct license got assigned. All that was done automatically by Adaxes
in exact accordance with the rule we’ve set up. Note that the same automation processes will be applied if, for example, we were importing new users from CSV, creating them using PowerShell or with any other method that goes through Adaxes. And similar automation rules could also be applied when creating Computers, Groups and other objects. Also, we’re not limited to just provisioning,
as with Business Rules Adaxes can automatically execute sets of actions not only after a new user is created, but also on other events in AD. For example, here I have a Business Rule that is triggered after an existing AD user is updated; If either the ‘City’ or ‘Department’
properties have changed, Adaxes will update the user’s location and group membership
accordingly. And note that these are the same Custom Commands
that we’ve seen in the onboarding rule. This means that I’m using exactly the same
logic here without the need to manually copy all the actions and conditions, which also makes it very easy to manage when something changes. So, with the rule in place, if at some point
the user gets relocated from NY to London, for example, and moved to the Accounting department, all I need to do manually is change those properties, and Adaxes will then do all the
rest for me. As we can see, it has automatically moved
the account to the London Office OU and also removed the user from the ‘Sales Staff’ group and added them to the ‘Accounting Staff’, just like we’ve set in the rule. Using the same approach, upon updating users,
Adaxes can also automatically assign or revoke O365 licenses, update user addresses, modify user profile parameters, and execute practically any other action. And you can also automate all sorts of other
activities with the help of Business Rules. For example, Adaxes can send notifications
to group owners when a new user is added to one of their groups, automatically disable
computer accounts when they’re moved to a specific OU and so on. You can also control, where exactly each rule will operate. For example, if your organization has several
offices in different locations, each of them might have their own sets of rules applied. So, if the Berlin office has its own separate
policies for how to handle user updates, which are different from the rest of my organization, I can have a separate rule for that, which, as you can see, is assigned only to the Berlin Office OU. This means that the Business Rule will be triggered only when users who are located in this particular OU are updated, so that
all the actions in the rule will be applied only to users from Berlin and to no one else. And apart from executing tasks upon certain
events in AD with Business Rules, Adaxes also allows the automatic execution of certain
activities on a periodic basis with the help of Scheduled Tasks. This can be useful, for example, for AD maintenance. Like, here I have two scheduled tasks that
maintain the users’ group membership and their locations in AD by executing corresponding
Custom Commands, which are again the same ones we’ve used in Business Rules after
creating and after updating users. So, if for some reason some users were moved
to an incorrect OU or added to a group that they don’t belong to, these tasks will automatically
identify and fix that. Finally, the last aspect of user lifecycle
management that we’ll be looking at today will be the last thing that needs to happen
to every user account — offboarding. Correctly deprovisioning the accounts of departing
users is often underestimated but it’s equally, if in fact not more, important than the other
procedures, as failing to do that properly, can become a massive pain in terms of security. So, let’s see how it can be automated. To do that in Adaxes we need a Custom Command,
which we can see here. This command actually comes out of the box, however I did slightly modify it for this demo. So, when it’s launched, it disables the
user account, resets the password to a random value, deletes the share for the home folder
and, if it’s empty, it will also delete the folder— however, I could instead archive
it or move it to another location, if I wanted to — and then the command will run a script,
removing the user’s entry from the SQL database, that was added during provisioning. After that, Adaxes will set mail forwarding
to the user’s manager, if there is one, and give the manager full access rights for
the mailbox. Then, the command will hide the user from
the Exchange address list, cancel all meetings organized by the user and convert the mailbox
into a shared mailbox, so that if it’s located in Exchange Online, you’ll no longer need
the user’s license for it. And after that, the command will revoke all
licenses, and instead of deleting the Office 365 account of the user, it will set account
status to Blocked, which is a recommended best practice. I can also add other actions to the Command,
for example, I can set it to move the user account to a separate OU, where all the terminated
users are stored, and I could also do things like remove the user from all groups, put the termination date and time into the Description property, delete the accounts of the user
from other connected systems and so on. So, let’s now switch to the Web Interface
and use the Command to deprovision our user. And, as you can see, all I need to do is launch a one-click command, confirm it and that’s it! After that, the account is now disabled, moved to the ‘Deprovisioned Users’ OU, hidden from address lists in Exchange, blocked for
Office 365, has all licenses revoked and so on. With Adaxes, it is also possible to configure
scheduled deprovisioning to terminate users on a certain date in the future. For these purposes I have a separate Custom
Command created and to make things a bit different, let’s have a look how it works on my phone. Here I’ve got a user that I want to terminate
and when I launch the ‘Schedule Deprovisioning’ command, I can simply pick a termination date in the pop-up, so that now Adaxes will deprovision the user on that day. And similarly to picking the termination date,
I can also add other options to control the deprovisioning process; for example, whether the user’s manager needs to be notified about the termination, for how long to keep the deprovisioned account before deleting it and so on. Automated deprovisioning can also be used in automated workflows, for example, to regularly remove inactive users from your environment. For these purposes, here I have a scheduled task that periodically goes through AD and if it finds a user that’s been inactive
for more than 12 weeks, it will execute the Deprovisioning command for the user. Then, if the account stays like that for another month and nobody claims it, Adaxes will delete it. And because deprovisioning and deleting accounts are sensitive operations, in both cases it will send the actions for approval, so they won’t be executed unless reviewed and approved by somebody, like a member of IT staff. So, with all the automation provided by Adaxes,
you can significantly reduce the resources that are required to manage the user lifecycle
in AD, Exchange and Office 365. You can make sure that everything happens exactly when it n needs to happen strictly following the rules you’ve set up. Thanks for watching.
