Microsoft Support checklist: save time with these tips
03.12.2019 Uncategorized 0
This article has been written to help you streamline your collaboration with Microsoft support when dealing with issues/bugs in Office 365.
We really don’t want to reach out to Microsoft support when we can fix the issue ourselves. Microsoft can help with this, but ideally all the common troubleshooting steps have already been covered before creating the ticket. This is pretty straightforward, but I’m also aware that people still reach out to Microsoft when there is no need to do this.
- Check the health dashboard and message center in the O365 admin center. Found nothing related? Then you can start with the investigation.
- Research it a bit online. Check the Microsoft Support twitter account and look at both the Tweets that they are receiving and sending out. You should also consider searching on the TechCommunity forum. Are they still investigating the issue and is it related to specific tenants? Make sure to create the ticket to let them know that you’re experiencing this as well. This information can help Microsoft to come up with a fix. You should also add a link to the conversation online as a reference.
- Try to reproduce the issue with your account in your own environment. Not happening there? Then you need to ask the user to make your account an admin in the environment to perform some tests. This is the preferred method for Teams as it generates a notification that you have given yourself access. When you can reproduce the issue with your account, then this means that the person that reported the issue to you doesn’t have to join the calls with Microsoft support.
- Investigate the environment. Are there any customizations, any workflows changing things automatically, customized permissions in the connected Site? Try to set up the same type of environment to figure out what is causing the issue and make sure to also test the default way to create an environment within O365.
- Sometimes issues only appear in existing or new environments. Make sure to include this in your test by always keeping several test environments as references.
- Try to reproduce the issue in a different tenant. You should have a test tenant, but you can also create an O365 trial tenant if needed. Is the issue tenant specific, then make sure to indicate this when creating the ticket and also mention all the tenant URL’s. You could also consider posting in the TechCommunity forum to ask other customers to test this for you and let you know if it’s impacting them. You can then add a link to the conversation inside the ticket you’re creating with Microsoft support. They will then realize that you’re keeping them up to date on the progress even-though this should ideally be done by Microsoft. It makes no sense for multiple customers to create tickets for obvious bugs that are appearing everywhere for everyone. This is why we sometimes have to work together to make sure that an issue gets the attention it deserves.
- Issue only appearing for the account of the user? Try to reproduce the issue while connecting to a different network and also try to perform a test on a different machine. Ask them to test while working from home or temporarily use their smartphone to share the Internet connection. A Virtual Machine with temporary access is an interesting solution, but you can also ask local IT to keep several laptops available for this purpose.
- Try to reproduce the issue using different browsers and make sure to test using an InCognito/InPrivate session. In one case a button in PowerBI wasn’t showing because of an adblocker add-in. Make sure to ask the users to exclude all O365 url’s to prevent this from happening in the future.
- Install Fiddler and analyze the traffic. You might notice something in the logs that can help with your investigation. Make sure to allow Fiddler to capture encrypted traffic and ideally you should run this on a VM as you need to close all other applications. Another option here is to create multiple accounts in Windows, you can then simply switch between the accounts and capture the trace.
- Let’s assume that everything points towards this being a bug (i.e. something Microsoft needs to fix). You need to attach the Fiddler log (working & non-working) and the PSR (built-in step-recorder in Windows) to the ticket. Provide a description of the issue and a summary of the steps that you have tried already (e.g. not related to account, machine, network and happening in all environments for all users). Don’t send Fiddler traces via email, this is pretty much the worst way to share this information. You could also use OneDrive or ask the engineer to provide a place for you to upload it. You have the option to attach 5 files to the ticket and you can ask the engineer to confirm that they have been download if you need to attach more files.
- When you have covered all the steps and basically proven that you’re dealing with a bug, then the engineer most likely will reach out to the senior escalation engineer. The senior escalation engineer is the interface between the engineer and the product group or engineering team. You need to help the engineer convince the senior escalation engineer to escalate the ticket.
- Are they pushing for a call when this clearly isn’t needed? Ask them to indicate what exactly they want to cover during this call. You shouldn’t waste your time showing something that they could have checked in the ticket (e.g. PSR) or something they could have easily reproduced it in their own tenant.
- Outlook has a feature that allows you to share your availability via a link (publish calendar). You can include this link when creating the ticket to make it easier for them to schedule the call, but keep in mind that this could result in you wasting time (see point above). You can also share this link later when the meeting is actually needed. Don’t spend too much time blanking out a screenshot of your calendar, chances are that no meetings/calls are needed this week.
- Don’t want them to call you to discuss the ticket? Make sure to indicate this when creating it. Chances are that they will call you outside of working hours when you do provide them your number, so it makes sense to indicate your timezone just in case. This is also why you should ideally have a work phone next to your personal one. There have been multiple cases where they simply find your phone number in archived tickets, so keep this in mind as well.
- Are they using LogMeIn to connect to your machine? Make sure to read the permissions the application is requesting before approving it. They recently faced a bug which resulted in LogMeIn always asking for full control. This is not something you should allow. Sometimes the engineers can engage with you via Microsoft Teams, this can really help when using it for chat or the call as it includes a desktop sharing feature.
- You can only increase the severity of a ticket if you’re covered by a Premier Support contract. Increasing to severity A makes sense if the issue has a significant impact on the business, but you do need to provide a phone number that can be reached 24/7 as you’ll receive calls from the CritSit (Critical Situation) manager. The CritSit manager won’t really dive into the technical details, but you should get regular updates on the progress. In some cases, someone from the engineering team joins the calls to explain what they’re doing to fix the issue. You can create tickets with severity level A, but you need to reach out to your TAM/SDM if you want to increase the severity of an existing ticket.
- When tickets with severity A are resolved, this should be followed up by an RCA (Root Cause Analysis). Make sure you have a good idea of why the issue happened and what Microsoft has done to prevent it from happening again in the future.
- The worst-case scenario is basically having to “escalate”. You can ask your TAM/SDM or the engineers themselves to have the ticket reassigned to a different engineer. Don’t waste too much of your time because someone isn’t willing to read the information you provided when creating the ticket. This is a clear indication of how much time you probably have to spend to get everything across.
- Feedback is important and it’s integrated into the support section in the O365 admin center. The engineer might call you, just to ask you to provide feedback. This seems a bit much when everything up to that point was covered without calls/meetings. Sometimes you have to ask the engineer to close the ticket as soon as they reach out (e.g. you didn’t test it properly the first time). Chances are that the engineer will still ask for feedback, but what exactly are you providing feedback on? Just make sure to provide positive feedback for engineers that really did their best to help you.
- You should create your own private internal Microsoft support community. This is a community where people can point out strange issues in O365. This shouldn’t be restricted to only an IT audience, you need an approximate representation of the entire company. You need people from IT, communications, VIP’s, tech-savvy users etc. It should be an audience that understands how important it is to stay connected with each other w.r.t. issues in O365. You don’t want everyone to reach out to the service desk or you specifically, you need people around you to be your eyes and ears and to provide the feedback you need to determine the impact and find the most optimal resolution.
- You should also have multiple large internal communities for Office 365 (e.g. dedicated community for PowerBI). You can set this up in Microsoft Teams, but Yammer is recommended because of the algorithm used to come up with suggestions and the fact that Teams is limited to max 5000 users. You can ask this community to check something for you, update them on issues they might be experiencing, share news on new (preview)features etc. You most likely have a ticketing system for IT related issues, but you actually want them to reach out to the community first. This allows others to check this and thereby help determine the impact. Having to deal with a lot of internal tickets for a known issue is in some cases a huge waste of time.
- Consider using placeholders within applications to let people know when there are issues. This could for example help prevent a lot of people from creating environments in Microsoft Teams if you’re covering this with a provisioning solution (request via a form).
Make sure to bookmark this article as we’re going to keep adding tips in the future.