Microsoft 365 represents a combination of Office 365, Windows 10 and Enterprise Mobility offerings – providing the most complete set of SaaS technologies that Microsoft has to offer. With Microsoft 365, organizations can deploy a complete solution encompassing both devices and applications, along with applying security and compliance policies to protect the entire suite.
This course will help you as you plan your deployment of Microsoft 365, along with configuring and managing your tenant once it’s deployed. It also covers setting up and managing a Microsoft 365 subscription for an enterprise – including managing identities, security, compliance and the supporting technologies in the Microsoft 365 stack.
This course focuses mainly on setting up and managing a Microsoft 365 tenant – including the process for setting up a trial tenant, adding your own domains, and converting your tenant beyond the trial to a fully functional production environment. Now, these steps can seem to be very easy – just click a few options, answer a few questions, and you’re done. In fact, it is that easy! However, if you’re not aware of the big picture and asking some important questions along the way, you can end up painting yourself into a corner and causing problems down the road. At best, you might need to redo some things, at worst, you leave yourself with problems on your hands that might be difficult to sort out later.
After you’re set up, we’ll move on to talking about some of the things you need to consider in your day to day monitoring and management of your Microsoft 365 Tenant and the services that make it up. We’re also going to run through a few demos – showing you some of the practical steps involved, along with some tips and tricks we’ve picked up along the way.
- Set up a new Microsoft 365 tenant and subscription
- Add domains to the tenant and configure them for the various service offerings
- Perform the day to day management of your users, including managing user accounts and license assignment
- Know how to monitor the various services in your M365 tenant and have a plan in place to respond to service alerts and manage service requests
This course is intended for people who:
- Want to become a Microsoft 365 administrator
- Are preparing to take the Microsoft’s MS-100 exam
To get the most from this course, you should have a general understanding of networking & server administration as well as IT fundamentals such as DNS, Active Directory and PowerShell.
It's helpful to realize that service alerts are tenant specific. Once an issues is known in Office 365 and an alert is released, it's scoped to all relevant and potentially impacted tenants. This gives you an authentic dashboard experience that you can follow when relaying information to your support teams and end-users. This also allows you to create an incident response plan appropriate to your organization's business needs and complexity as we as one that's properly suited to your existing service desk incident response process.
For the purpose of this exercise, let's consider three different incident support scenarios of varying degrees of impact. The first scenario would be one where you know that you have users were impacted and Microsoft has published a corresponding incident in the dashboard. Your workflow would likely be to give your service desk a talk track, potentially stand up an automated voice response to deflect help desk calls as well as to notify senior management.
Depending on the incident and whether or not there's a workaround, you'd use this information to provide your service desk with the response that will allow them to address the tickets coming in by impacted users or at least a method to determine if the calls that are coming in are related to the existing issue being reported in the Service Health Dashboard. The second scenario is one where your service desk is receiving calls and support tickets or potentially seeing alerts from tools monitoring service health. We'll talk more about that a bit later.
While Microsoft hasn't posted anything in the portal yet, in this case, it might be that Microsoft simply hasn't reported on the issue yet or it might be a client's had issue or it could be a problem with your internet service provider In this scenario, you would likely stand up an incident bridge on your side to begin troubleshooting the scope and the root cause of the issue. At this point, you'd likely give your service desk a heads up and engage senior management. You would also want to pull in Microsoft support once your triage process has determined that a support ticket is your next step. The resolution to this scenario is either going to be troubleshooting through to a solution for your issues or Microsoft posting an alert in the portal with either timeline of a fix or a workaround.
At this point, your scenario goes back to the first scenario we mentioned. If you haven't arrived at a fixed tree of troubleshooting and support tickets, you'd provide your service desk with a talk track, automated response et cetera. Of course that the issue has been resolved or a workaround provided, the now would be your go to response to incoming tickets, resolve the issue for your users. The important key here is that your service desk has the tools they need to either resolve the incoming issues or is prepared to communicate to end-users while the problem is being further investigated or a fix is being worked on. Scenario three is where Microsoft had posted an issue that has major impact like this incident alert for Teams but no users have started calling in or reporting the issue yet.
In this incident, your response might be to alert your service desk team as well as having your higher tier engineers on standby to respond when tickets come in. Your workflow at this point would be to again, give your service desk communication they can pass on to the end-user, ask your service desk to be on high alert and to page the appropriate team if they start receiving calls about the issue and also email senior management to give them advanced notice of a potentially high impact incident that may soon start to affect your business. Again you're going to want to be looking at your incident response from a severity and impact perspective.
Looking again at this team's issue, you can see into the more detail section that impacted users can still access Teams on a mobile device while Microsoft continues to investigate and diagnose the issue. Now this becomes a different conversation for you and your service team. What are your current use cases for Teams and will your users be able to work well enough in Teams on their mobile devices until the issue has been resolved? Have you deployed Teams to your mobile users already or will you need to push out the application to your managed mobile devices? Are you using Intune to manage the application deployment or do you need to advise your users to download and install Teams themselves? Does your security stance allow users to use their own personal devices or are your users restricted to corporate devices only for business functions? You can see from the questions above that the workaround provided by Microsoft might be an easy fix. Maybe mobile works for everyone and it's business as usual until service is restored. It also might be quite possible that the workaround doesn't fit within your business function or security protocols.
In which case you can have to make some decisions and potentially some concessions to allow the business to function as they need to without compromising your security and service integrity. Regardless of your ultimate approach, the important key here is that you've been able to build out a logical framework of incident response based on the information that Microsoft has made available to you in the Service Health Dashboard. And this information has empowered your service desk to be more responsive and hopefully to provide a better end-user experience.
Jeremy Dahl is a Senior Technology Consultant who has spent the last 8 years focusing on Microsoft 365 technologies and has been an Office 365 MVP for the last 6 years. Jeremy is a self-proclaimed cloud addict who architects technology solutions that combine cloud technologies with on-premises solutions, allowing organizations to make the most of their existing infrastructure while still taking full advantage of the agility and scalability of what the cloud has to offer.
Jeremy can be found blogging about Microsoft 365 technologies on his website, masterandcmdr.com, and evangelizing the Microsoft cloud on Twitter.