Показать сообщение отдельно
Старый 28.01.2019, 22:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
powerobjects: Decommissioning a System Administrator
Источник: https://www.powerobjects.com/2019/01...administrator/
==============


What happens when your Dynamics 365 for Customer Engagement system administrator decides to leave the company? Ugh, right? It’s not something we like to think about, but it is certainly a very real business scenario. In today’s post we’ll walk through all the things that need to be considered, contemplated, and changed when this happens, as well as how to avoid these potential problems the next time your system admin jumps ship.

First, when this scenario does reveal its ugly head in your organization, which of the following should you do? (Hint: there’s only one right answer.)

1. Panic.

2. Offer him/her a much higher salary to stay.

3. Disable his/her user record and just pretend everything is going to be ok.

4. Quickly, carefully, and efficiently analyze your system and make the necessary adjustments.

Hopefully, your answer is option 4 – after all, it’s the right answer. (Well, unless you have an unlimited budget, in which case you may want to consider option 2.) So, let’s get started on quickly, carefully, and efficiently analyzing the system and making necessary adjustments.

For Immediate Consideration


Most D365 for Customer Engagement system admins have a variety of roles within a company. They may be responsible for:
  • Providing end-user support and training
  • Creating and updating documentation
  • Importing solutions
  • Development work
In other words, they very well may know the system inside and out and likely have their hands in just about everything. So, not only is the loss of their knowledge a potential challenge, but their login credentials may be tied to many various processes within your application. This means that disabling their user credentials or changing their password once they leave the company is likely to leave you with broken processes, errors, loss of functionality, and plenty of headaches.

But from a security perspective, they can’t remain an active user either. So, once again… what can you do – specifically – to avoid those headaches? And no, enticing them to stay by doubling their paycheck still isn’t the right answer. Instead, let’s go step-by-step to ensure we keep your system up and running at full functionality.

Processes (Workflows and Business Process Flows)


Since workflows run in a user’s context, we need to first reassign any workflows and business process flows that are owned by the former system admin. In Settings > Processes, find any activated processes that are owned by him/her and reassign them – ideally to the new system admin, but if that person is not identified or hired yet, reassign them in the interim either to someone with sufficient system privileges or to a Service Account (more on this later). Importantly, don’t forget to reactivate each process afterwards.

Email


If your system has any automation in terms of sending emails, you must check whether any of those emails are being sent from your former system admin. If they exist in any To, Cc, or Bcc fields, that’s ok – you can (if you choose to) leave them without causing future failures. Having said that, our recommended best practice is to remove them.

If they exist in the From field of any emails – typically created via workflow send email steps, it means all those emails will be sent in the context of that user’s mailbox. Once the person if disabled from the system, those emails cannot be delivered. This is likely to occur when you have workflows designed to send notifications in the event of certain activities within Dynamics 365. For example, you may have a case assignment workflow that emails the new owner when they have been assigned a case – if you want that email to be sent and received, you’ll need to change it so that the From field is an active user (more on this later).

Integrations


This is where it gets fun!

So, what if your departing system admin used his/her credentials to set up external connections into CRM? If so, you now know two things:

1. This admin was either doing a lackadaisical job or was focused strictly on guaranteeing job security – in either case, at least now you know for sure that you don’t want to double that salary!

2. You have problems that need to be dealt with right away.

You must examine all of your external integrations, including:
  • SSIS
  • Scribe
  • PowerPack
  • Portals
  • Email router
  • Any other custom integrations
Wherever necessary, update the credentials – preferably to a service account with the necessary rights. For example, if you have an active cloud-based PowerPack, such a PowerSurveyPlus, you will need to open the solution and update the username and password in the credentials area. (To learn how, scroll down to the Registration section on this page.)

Personal Views, Dashboards, and Other Records


This is not as critical as the previous items because a personal view or dashboard that has been shared to multiple people will not be affected if the original owner is disabled. However, unless Assign (or other rights beyond just Read) have also been shared, you may be stuck with these Views and Dashboards… forever! That’s right, you’ll never be able to change them. What that means is that if your departing system admin (let’s call him Aaron) created a Contact View called Aaron’s Team and shared it to others with read-only access, every person with whom he/she shared it will forever have this View – and because views are listed alphabetically, they’ll suffer the added inconvenience of Aaron’s Team showing up first forevermore!

Luckily, that’s not exactly true. How do you make it go away? Use the magical REASSIGN RECORDS button (highlighted below) on the user record – it will reassign all records and views to someone else. Phew!



The time it takes to complete reassignment will depend on a few different things, including the number of records to be reassigned and whether or not the reassignments cross business units (reassigning records leads to Dynamics 365 adjusting the record-sharing table in the background).

Disabling the User


The last step – disabling the user – is the easiest. You can do this from the Office 365 portal by simply removing the user’s Customer Engagement license (alternatively, you can remove all security roles).

Preventing this in the Future


So, what’s the biggest lesson learned here? “SERVICE ACCOUNTS!”

Need to see that again? Here it is, in more detail this time: “USE SERVICE ACCOUNTS!”

Here’s what we mean:

In many Dynamics 365 for Customer Engagement deployments – and in all CRM on-premises environments – user logins are tied to an Active Directory user within the company (or you can also authenticate users directly within Office 365). In either scenario, you have the option to create non-user accounts. These are logins that only a handful of people in the company have access to and that are not tied to any particular individual. These logins have many different uses, and they can be configured to have full access to your Dynamics 365 application. There are different ways to reference this type of login, but for the purposes of this blog, we’ll refer to it as a Service Account (recall that we mentioned these earlier and promised to get back to them).

So, if you have an activated workflow that does not need to be assigned to a specific individual, the best practice is to not assign yourself (or the developer) as the owner. Instead, assign it to a Service Account and activate it. And if you have a more complex setup where workflow owners belong to different business units, you can easily create a unique Service Account for each use case.

The end result of this approach? In the event that a system admin leaves your company, you can quickly and safely change the password of the Service Account(s) being used to run workflows – without impacting anything.

Note that it is also a must to always use a Service Account for any integration that connects to Dynamics 365 externally, such as SSIS, Scribe, Email router, etc. And we always recommend using a different account for each process, as doing so provides two clear benefits:
  • If your Job or Integration is updating records, the audit trail will show that your specific Service Account did the update. For example, if you have an SSIS job called Job ABC and it is configured to connect to D365 through a user called Job ABC Service Account, then you will easily know all the updates that your job is doing to your system, since the audit history and Modified By and Created By fields will always reflect this user. But if you run all your jobs through the same Service Account, it will be harder to differentiate how each change occurred.
  • You will also be able to deploy your integrations and jobs on a “least privilege” basis, which is always a security best practice. For instance, do you have an Integration whose only function is to read Contact information and update the Address? If so, it probably doesn’t need access to much else beyond Contacts, and you can provide it a custom security role that only grants the rights it needs.
But what about auto emails? If you are sending email as an end user, do you have other options (again, we mentioned this earlier and promised to come back to it)? The answer is yes – you can send as a Queue instead, since a Queue can be configured as any email address and display name. Now, there are further considerations to take if you want to send as a Queue instead of an end user, and some of it may depend on your company’s email policies and how your outgoing email delivery is configured. But if you have automation to send emails from your system based on records being created or updated, chances are you don’t need to set the From field as an individual. In those cases, you will want to definitely consider using a Queue and possibly using a no-reply address … or even an e-mail that does not exist in your D365 Customer Engagement deployment. The bottom line is that you have options – and sending email as an end user is not always the best one.

So, there you have it… what to do when your system admin jumps ship and how to avoid the ensuing problems in the future. We hope this was helpful (and saves you some money and headaches in the process).

Don’t forget to subscribe to our blog for more Dynamics 365 tips!

Happy Dynamics 365’ing!

The post Decommissioning a System Administrator appeared first on Microsoft Dynamics 365 | PowerObjects.



Источник: https://www.powerobjects.com/2019/01...administrator/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.