Support Ticket Examples.

Real examples of US Cloud Support tickets across all Microsoft software

Carefully curated testimonials or even reference calls with friendly enterprise customers don’t really give you a sense of a potential partner’s true capabilities. One way that we have found to give enterprise IT professionals a better sense of what we do is to provide a window into our actual Microsoft break-fix ticket details.

Below are a few examples of real Microsoft Enterprise Support tickets that give a sense of what kind of technical problems we tackle on a daily basis. In addition to comprehensive Microsoft portfolio coverage, enterprises enjoy 25% faster resolution than MS Premier/Unified. All delivered by US domestic teams and backed by the industry's only response time and escalation SLAs.
Microsoft Enterprise Support at US Cloud

Azure

Azure

Problem: A user reports that their Azure Virtual Machine (VM) is not starting up after resizing the VM's resources, such as CPU or memory. The user had shut down the VM before resizing and had followed the documented procedure for resizing. After resizing and starting the VM, the Azure portal shows that the VM is running, but the user is unable to connect to it using Remote Desktop Protocol (RDP).

Resolution: After investigating the issue, it was found that the Virtual Machine Agent on the Azure VM was not responding correctly. This was due to the resource resize operation disrupting the communication between the VM Agent and the Azure fabric controller. To resolve the issue, the Virtual Machine Agent was restarted manually using the Azure PowerShell module. After the agent restart, the VM was able to start up successfully, and the user was able to connect to it using RDP.

Azure

Problem: A customer reports that their Azure Virtual Machine Scale Sets (VMSS) are not scaling out to meet the increased demand on their website during peak hours. They have checked their scaling policies and verified that they should be scaling out, but the VMSS instances are not being created.

Resolution: The Azure support team investigates the issue and discovers that the autoscale rules are configured to use the "average CPU usage" metric, which is not increasing during the peak hours due to other factors. To resolve the issue, the team recommends changing the autoscale rules to use a different metric, such as "requests per second", which is more indicative of the website's increased demand. The customer implements this change and the VMSS instances begin scaling out successfully during peak hours. The issue is resolved.

Azure Intune

Problem: The client was attempting to set Policies for Devices Intune Managed for two Phases to force Windows Updates to process. Policies were applied, but corresponding devices were not taking action. The client opened a ticket with US Cloud to help review the policies and learn what they may be missing in order to get the devices to process outstanding updates.

Resolution: US Cloud researched the issue and then advised the client that the likely problem revolved around Microsoft Teams Rooms App (MTR). MTR has built in logic for a Windows 10 feature that only allows updates (for devices running Microsoft Teams Rooms) after six months from the time when Windows makes a release update. This is accomplished by putting a special block for Microsoft Teams Rooms devices on the Windows Update for Business channel (that is, Semi-Annual Channel) and through the app settings. During this blocked period Microsoft performs various tests both in-house and through device OEM partners to make sure that new Windows 10 feature release is working in harmony with the Microsoft Teams Rooms app and peripherals connected to it.

This is important to both ensure device security, consistent user experience and to make sure quality of experiences offered through Microsoft Teams Rooms app. The issue and cause were clarified in detail for the client and IT was able to reset expectations regarding those delayed updates.

Azure AD

Problem: On a Windows Server running Azure AD Connect, the sync process is not working properly. The synchronization status shows that the last sync was not successful, and changes made in the on-premises Active Directory are not being replicated to Azure AD

Resolution: After checking the Azure AD Connect installation and verifying that the service was running, it was found that the issue was related to the firewall settings. The necessary ports for communication with Azure AD were not open in the Windows Firewall. To resolve the issue, the required ports were opened in the firewall by creating inbound and outbound rules. After making these changes, the sync process ran successfully and changes in the on-premises Active Directory were replicated to Azure AD.

Azure DevOps

Problem: During the deployment process, an Azure DevOps pipeline failed to run, causing a delay in the release of the application. The error message indicated that a required package was missing, but it was unclear why the package was not found.

Resolution: The issue was resolved by adding the missing package to the project's dependencies and rebuilding the application. Additionally, the pipeline was updated to include a check for all required dependencies before running, which helped to prevent similar issues in the future. The team also implemented automated testing to catch any issues before they could cause delays in the release process.

Azure Resource Manager

Problem: During the deployment of a new Azure Resource Manager (ARM) template, the deployment fails with an error message stating that a resource could not be created or updated.

Resolution: To resolve the issue, the resource group was checked to ensure that it existed and that the correct permissions were assigned. It was discovered that the necessary permissions were missing, so the appropriate permissions were granted to the necessary user and service principal. The deployment was then retried, and it completed successfully. The resource was updated as expected.

Microsoft 365

M365 Defender

Problem: M365 Defender is not detecting threats on Windows devices even though the appropriate policies are in place and the devices are up to date.

Resolution: The issue was resolved by checking the M365 Defender settings and verifying that all policies were properly configured. The next step was to check if the latest updates for Windows Defender were installed on the affected devices. After confirming the updates were installed, the devices were scanned for threats again, and the issue was resolved. Finally, additional measures were put in place to ensure that M365 Defender was continuously monitoring and detecting threats on all Windows devices.

M365 Power BI

Problem: A user reported that their Power BI dashboard was not automatically refreshing, even though they had set up automatic refresh on a schedule.

Resolution: After investigating the issue, it was determined that the user's data source credentials were not saved properly, which caused the refresh to fail. The data source credentials were updated with the correct login information and the automatic refresh schedule was restarted. The dashboard was then able to refresh successfully on the set schedule. The user was advised to double-check their data source credentials in the future when experiencing similar issues.

M365 PowerApps

Problem: PowerApps form is not submitting data to SharePoint List

Resolution: We first checked that the SharePoint List was properly configured to accept data from the PowerApps form. Then, we confirmed that the form's connection to the SharePoint List was functioning correctly. Next, we reviewed the OnSelect function of the submit button to ensure that it was properly linked to the SharePoint List. Finally, we checked for any missing or incorrect formulas or expressions within the form that could be causing the issue. After these steps, we were able to successfully submit data from the PowerApps form to the SharePoint List.

M365 SharePoint

Problem: A user reported that they were unable to view the contents of a SharePoint list in M365. Whenever they clicked on the list, the page would load, but the list items would not appear.

Resolution: Our team investigated the issue and found that the user had inadvertently changed the view settings of the list. We advised the user to select a different view or to reset the current view to its default settings. After following our instructions, the user was able to view the list contents without any further issues. We also reminded the user to be careful when modifying list settings to avoid unintended consequences.

M365 Teams

Problem: The client had transitioned to using Teams recently and user errors were still common. It was discovered that some critical Teams Messages had been accidentally deleted and all efforts to recover them by the internal IT team had been unsuccessful.

Resolution: US Cloud first obtained background and details about the messages and confirmed that they / the Team had actually been deleted vs. archived, which it had. The US Cloud engineers then checked to see if the client’s instance of Microsoft Teams had possibly been configured with ‘Legal Hold’. Although not a feature commonly used by IT teams, Legal hold is often enabled at set up to ensure all information and interactions within Teams is kept indefinitely so someone can search and export the evidence for a court of law. Litigation Hold will maintain a copy of the data even after it has been deleted. A user can still delete the content as they’d expect, but Microsoft will continue to retain the data in a hidden location only administrators can access.

The US Cloud team found that the deleted Teams Room was indeed backed-up on Litigation and the messages were restored. The Audit logs were reviewed during a screen share and it was found that there were no levels of auditing for this particular type of event. US Cloud advised the client to review from the Exchange side and discovered the user who had deleted the messages. They were then guided through adjusting the relevant permissions to resolve issue and prevent the incident from occurring again.

M365 Exchange

Problem: An Exchange Server has stopped sending or receiving emails. Upon investigation, it is found that the Exchange Server's transport services have stopped working. The root cause of the issue is traced back to an expired SSL certificate that is needed for secure communication between the Exchange Server and the email clients.

Resolution: The expired SSL certificate is replaced with a valid one, and the Exchange Server transport services are restarted. The Exchange Server is then tested for email sending and receiving functionality, and it is confirmed that the issue has been resolved. To prevent similar issues in the future, a monitoring system is set up to alert the IT team if any SSL certificates are nearing expiration.

M365 OneDrive

Problem: Users are experiencing issues syncing their Office documents with OneDrive, resulting in sync errors. Some users are also seeing duplicate files created in their OneDrive folder.

Resolution: After investigating the issue, it was found that the sync errors were caused by a conflict with the Office Upload Center. The solution involved disabling the Office Upload Center and then repairing Microsoft Office. The duplicate files were resolved by turning off Files On-Demand in OneDrive settings. After these changes were made, the sync errors and duplicate files were resolved and users were able to sync their Office documents with OneDrive without any issues.

M365 Flow

Problem: A user had reported that their Microsoft Flow workflow was not triggering despite meeting the trigger conditions. They had already checked that the trigger condition was being met and that their account had the necessary permissions to run the workflow.

Resolution: The support team investigated the issue and found it to be related to a known bug in the Microsoft Flow service. They applied a patch to the affected server, and the user's workflow was then able to trigger successfully. The team advised the user to check the Microsoft Flow service health dashboard in case of any future outages or issues with the service.

M365 Planner

Problem: A team reports that task assignments in Microsoft Planner are not updating for shared plans. When a team member is assigned a task, the changes do not reflect for other team members in real-time. The team has confirmed that all users are properly connected to the shared plan and have the necessary permissions.

Resolution: After extensive investigation, it is discovered that the issue stems from a synchronization delay between the Planner server and the user's local cache. The support team applies a patch to improve the synchronization process and reduce the delay. Additionally, the team advises the affected users to manually refresh their local cache by clearing temporary files and restarting the Planner application. This ensures that task assignments update accurately and in a timely manner for all team members in the shared plan.

Dynamics

Dynamics 365

Problem: Users were experiencing slow performance when using Dynamics 365 in the web client. It was causing frustration and slowing down productivity.

Resolution: After investigating the issue, it was discovered that a few custom scripts were running in the background, which were not optimized for performance. These scripts were causing the web client to slow down. The solution was to optimize the custom scripts by removing unnecessary loops, reducing the number of DOM manipulations, and optimizing the queries. After implementing the optimized scripts, the web client's performance significantly improved, and users no longer experienced slow performance.

Dynamics AX

Problem: During an update installation for Dynamics AX, an error message appears indicating that the installation has failed due to missing dependencies. After checking the dependencies, it is found that one of the required third-party components is not installed on the server.

Resolution: The missing component is identified and installed on the server. The update installation is then retried, and it completes successfully. The system is tested to ensure that the update did not cause any issues with the functionality of Dynamics AX. Finally, documentation is updated to reflect the newly installed component as a required dependency for future installations or upgrades.

Dynamics GP

Problem: A user reports an error message when attempting to post a transaction in Dynamics GP. The error message states that the batch is being edited by another user and cannot be posted. However, the user confirms that they are the only user accessing the batch.

Resolution: The issue is found to be caused by a locking issue in the database. The support team identifies and removes the lock, allowing the user to successfully post the transaction. The team recommends that the user performs regular database maintenance tasks, such as running database integrity checks and clearing out old transaction data, to avoid similar issues in the future.

Dynamics F&O

Problem: A Dynamics F&O user reported an error message that appeared while opening a specific form. The error message indicated a problem with an object on the form and prevented the user from opening it. The user tried to refresh the form, clear their cache, and even restarted the system, but the error persisted.

Resolution: The issue was found to be caused by a data inconsistency in the Dynamics F&O database. The database administrator ran a query to identify the specific data inconsistency and corrected it. After the data inconsistency was resolved, the user was able to open the form without encountering the error message. The administrator advised the user to report any similar issues immediately to prevent further database inconsistencies.

Windows Server

Windows Server

Problem: Client had Windows Server 2012 running a repeating task scheduled to reboot a server weekly. Without any obvious cause, the server began kicking off that task earlier in week, and then again on the scheduled time.

Resolution: US Cloud first researched to ensure the system was not in hibernating mode. In addition, there were no events related to Kernel Power loss in the event logs, nor an event ID 42 in the logs as well. US Cloud engineers instructed the client to remove the AC condition from the task and ensure that there were no GPO settings or a SCCM Reboot Schedule setup. The client reset task scheduler to be configured for Windows Server 2012 r2, as it was set for 2008. After changes were made, the client let the task run with the change over the weekend and confirmed the issue was resolved.

Windows Server

Problem: A Windows Server administrator reported that their server kept crashing and becoming unresponsive. Upon investigation, they found that the server was crashing due to a particular service becoming unresponsive, but they were unable to determine the cause of the issue. They tried restarting the service and the server, but the problem persisted.

Resolution: The team recommended using the Debug Diagnostic Tool to identify the cause of the unresponsive service. They analyzed the memory dump created by the tool and found that the issue was being caused by a specific function within the service. They investigated the function and found that it was attempting to access a resource that was no longer available. They updated the function to handle this scenario correctly, and the server stopped crashing.

Windows Server

Problem: A Windows Server 2019 virtual machine (VM) was unable to join the domain, even after providing the correct credentials. The error message indicated a secure channel issue, which prevented the VM from establishing a connection with the domain controller. The administrator tried resetting the computer account and restoring the secure channel using the Netdom command, but the issue persisted.

Resolution: The team discovered that the VM's clock was out of sync with the domain controller's clock by more than 5 minutes, causing the secure channel to fail. The administrator updated the VM's clock to match the domain controller's clock, and the VM was able to join the domain successfully. The team also recommended configuring time synchronization on the VM to ensure that the clock remained in sync with the domain controller's clock.

Windows Server - Active Directory

Problem: AWindows Server administrator reported an issue with Active Directory replication between two domain controllers. The administrator checked network connectivity and DNS configuration but was unable to resolve the replication failure. The secure channel between the domain controllers was reset, but the issue persisted.

Resolution: The support team investigated and found a mismatch in the security identifier (SID) of the domain controllers. To resolve the issue, the team recommended performing a metadata cleanup of the domain controllers to remove any invalid or orphaned entries. The cleanup was performed, and the SIDs were then matching between the domain controllers. Replication was restarted, and the domain controllers were able to communicate with each other and replicate Active Directory data successfully, resolving the issue.

Windows Server - AD Federation

Problem: A Windows Server administrator reported experiencing issues with ADFS authentication, as users were unable to log in to the federated application. After verifying that the certificates were valid and the trust relationship between the federation servers was working correctly, the administrator checked the event logs and found error messages indicating that the ADFS service was unable to connect to the SQL database.

Resolution: The support team investigated the issue and found that it was caused by the ADFS service account's misconfiguration in the SQL database. The team recommended that the administrator checks the SQL Server database permissions for the ADFS service account and ensure that it has the appropriate permissions to access the required tables. The administrator followed the team's recommendation and updated the service account permissions in the SQL database. After that, the ADFS service was able to connect to the database and authenticate users without any issues. The issue was resolved.

Windows Server - Group Policy

Problem: A Windows Server administrator reported that Group Policy settings are not being applied to client computers in the domain. The administrator has verified that the Group Policy objects are linked to the appropriate organizational units (OUs) and that the permissions are set correctly, but the settings are still not being applied. The administrator has also checked the event logs on the client computers and found error messages indicating that Group Policy processing is failing.

Resolution: After investigating the issue, the support team determined that the problem is caused by corruption of the Group Policy cache on the client computers. To resolve the issue, the team recommended clearing the Group Policy cache on the client computers by deleting the contents of the C:\Windows\System32\GroupPolicy folder. The administrator performed this action on the client computers, and the Group Policy settings were then applied successfully. The issue was resolved, and the client computers were receiving and applying Group Policy settings correctly.

Windows Server - PowerShell

Problem: A Windows Server administrator reports that PowerShell commands are failing to run on their server. The administrator has tried running basic commands such as Get-ChildItem and Get-Service, but they all fail with error messages indicating that the commands are not recognized. The administrator has also verified that the PowerShell version installed on the server is up-to-date and that the execution policy is set to allow scripts to run.

Resolution: The support team determines that the problem is caused by a missing environment variable that is required for PowerShell to run correctly. To resolve the issue, the team recommends setting the PATH environment variable to include the folder path containing the PowerShell executable. The administrator adds the folder path to the PATH environment variable, and PowerShell commands are then able to run successfully. The issue is resolved, and the administrator can now use PowerShell commands on the server.

Windows Server - Hyper-V

Problem: We encountered a common issue where a virtual machine was not able to connect to the network on a Hyper-V server. This caused communication issues between the virtual machine and other network devices.

Resolution: The issue of virtual machine network connectivity on the Hyper-V server was resolved by checking the virtual switch configuration and updating the virtual machine's network adapter settings. We found that the virtual switch configuration was incorrect and needed to be updated to allow the virtual machine to connect to the network. Additionally, we updated the virtual machine's network adapter settings to use the correct network configuration.

Windows Server - Remote Desktop

Problem: We encountered a common issue where a remote desktop connection was failing on a Windows Server. This prevented remote access to the server and caused communication issues between the server and remote devices.

Resolution: To resolve the issue, we checked the Remote Desktop Services event logs and found an error stating that the RDP listener was not available. We then ran a PowerShell script to restart the RDP listener service, which resolved the issue and allowed remote access to the server.

Windows Server - IIS

Problem: We encountered a common issue where the web server was not responding on a Windows Server with IIS. This prevented access to the website and caused communication issues between the server and remote devices.

Resolution: To resolve this issue, we checked the IIS logs and found an error stating that the website was unable to bind to a specific IP address. We then checked the network configuration and found that the IP address was not configured correctly. We updated the network configuration to use the correct IP address and restarted the website, which resolved the issue and allowed access to the website.

Windows Server - DFS

Problem: DFS replication stops working between two Windows Server machines, resulting in files not being synchronized properly and causing data inconsistencies.

Resolution: We found that the issue was due to an outdated network driver on one of the machines. After updating the driver, we restarted the DFS replication service and forced a synchronization between the two servers. This resolved the issue and ensured that files were being synchronized properly between the servers.

Windows Server - Identity Manager

Problem: Users are unable to log in to applications due to synchronization issues between the Windows Server Active Directory and the Identity Manager system.

Resolution: We discovered that the synchronization service account had insufficient permissions to access the necessary Active Directory resources. We updated the service account with the appropriate permissions and restarted the synchronization service. After verifying the synchronization process was running smoothly, users were able to log in to the affected applications without any further issues.

On-Premise

On-Premise - System Center

Problem: The System Center Operations Manager (SCOM) console is slow to load and responds sluggishly to user input.

Resolution: We identified that the SCOM database was experiencing performance issues due to excessive database growth. We performed a database cleanup and optimization process that involved purging old data, re-indexing tables, and updating statistics. After completing the optimization process, the SCOM console performance significantly improved, and users reported faster load times and improved responsiveness.

On-Premise - SharePoint

Problem: A Sharepoint administrator reports that users are unable to access a specific document library on the Sharepoint site. The administrator has checked the permissions on the library and verified that the users have the appropriate permissions, but the issue still persists. The administrator has also checked the site and server logs and found no errors related to the issue.

Resolution: After further investigation, the support team discovers that the issue is caused by corrupted permissions on the library. To resolve the issue, the team recommends resetting the library permissions to their default settings using PowerShell. The administrator runs the PowerShell script and verifies that the library permissions have been reset. The users are then able to access the library and the issue is resolved.

On-Premise - Exchange

Problem: MS Exchange database is not mounting, and users are unable to access their emails. The Exchange administrator has verified that the database is in a clean shutdown state, and there is enough disk space available. However, when trying to mount the database, it fails with an error message indicating that the database is corrupted.

Resolution: After investigating the issue, the support team determines that the Exchange database is corrupted, and the logs are not being replayed. To resolve the issue, the team recommends restoring the database from the latest backup and replaying the logs. The administrator restores the database from the backup and replays the logs, and the database is mounted successfully. The issue is resolved, and users are now able to access their emails.

On-Premise - BizTalk

Problem: A BizTalk administrator reports that they are experiencing an issue with the sending and receiving of messages between two systems. The administrator has verified that the send port and receive locations are configured correctly, but messages are still not being processed. The administrator has also checked the event logs and found error messages indicating that the messages are being suspended due to a schema validation error.

Resolution: After investigating the issue, the support team determines that the problem is caused by a mismatch between the message schema and the schema that is expected by the receiving system. To resolve the issue, the team recommends updating the message schema to match the expected schema of the receiving system. The administrator updates the message schema and restarts the send port and receive location, and messages are then processed successfully. The issue is resolved.

On-Premise - SQL Server

Problem: A Windows Server administrator reports that an on-premise SQL Server database is unresponsive, and users are unable to access it. The administrator has verified that the server hardware is functioning correctly and that there are no network connectivity issues. The administrator has also checked the SQL Server error logs and found error messages indicating that the database is encountering transactional deadlocks.

Resolution: After analyzing the deadlock information, the support team determines that the issue is caused by conflicting queries from different transactions. To resolve the issue, the team recommends modifying the SQL queries to ensure that they are not conflicting with each other. The administrator works with the application developers to modify the SQL queries, and the database becomes responsive again. The issue is resolved, and users are able to access the database without any issues.

On-Premise - Skype Business

Problem: A user reports that they are unable to view messages in a persistent chat room in Skype for Business. Other users are able to see the messages, but this user is not. The administrator has verified that the user has the appropriate permissions for the chat room and that the chat room is functioning properly, but the messages still cannot be seen by the user.

Resolution: After investigating the issue, the support team discovers that the user's Skype for Business client is not syncing properly with the server. To resolve the issue, the team recommends clearing the user's Skype for Business cache by deleting the contents of the following folders: \Lync and \Lync\sip_USERNAME. The user performs this action on their client, and the messages in the persistent chat room are then displayed correctly. The issue is resolved.

Developer

Developer - Edge Browser

Problem: When accessing a webpage from a different domain, the Edge browser displays an error message stating that the webpage cannot be accessed due to a "Cross-Origin Resource Sharing" (CORS) policy issue. This error prevents the webpage from loading properly and can disrupt the user's browsing experience.

Resolution: To resolve the CORS issue, we enabled the "Access data sources across domains" option in the "Internet Options" settings within Edge. We also updated the server-side code to include the appropriate CORS headers to allow cross-origin requests. After making these changes, we tested the application again and confirmed that the CORS issue was resolved.

Developer - Visual Studio

Problem: A developer reported that their Visual Studio build was failing with an MSB3073 error, indicating that a command had exited with a non-zero exit code. This error occurred when the developer attempted to run a post-build command that copied built files to a specific location on the filesystem. The developer had confirmed that the command worked correctly when run manually from the command line.

Resolution: Upon investigation, the support team found that the MSB3073 error was caused by Visual Studio attempting to run the post-build command before it had completed building all of the project's dependencies. To resolve the issue, the support team recommended adding a dependency on the "BeforeTargets" attribute of the "Copy" target in the project file. This ensured that the post-build command was executed after all dependencies had been built successfully. The developer made this change to the project file and was able to build successfully without encountering the MSB3073 error.

Developer - .Net Development

Problem: A .NET developer reported that their ASP.NET Core application was throwing a System.InvalidOperationException error on startup with the message "Unable to resolve service for type". Despite trying various solutions like rebuilding the project, cleaning the solution, and clearing the NuGet package cache, the error was still preventing the application from starting up correctly.

Resolution: After investigating the issue, the support team found that the error was caused by a mismatch between the registered services and the dependencies in the application. To resolve the issue, they recommended checking the ConfigureServices method in the Startup.cs file to ensure that all dependencies were registered correctly. The developer updated the registration code, and the application was then able to start up without the System.InvalidOperationException error.

Developer - Outlook

Problem: This very large and famed 100-year-old US retailer turned e-tailer suddenly found that none of its employee user base could login and access their SharePoint site. The company used this hub as their primary internal document sharing and access hub and the lack of access was causing significant disruption to their business.

Resolution: A US Cloud ticket was opened. And after an initial quick response and triage, a Premier engineer was engaged that day. After digging into recent activity with the client it was discovered that the certificate for SharePoint servers had been updated very recently. US Cloud determined that this was most likely the cause of the problem and advised the client to import the “SharePoint Root Authority” certificate to the Trusted Root Cert store on all SharePoint servers. The client completed that step and the log-in ability for all users was restored.

Developer - Office Suite

Problem: A developer reported that their VBA macro in Excel was running slowly and consuming a lot of memory, causing Excel to crash. The macro was previously running without any issues, but after adding new functionality and increasing the size of the data being processed, it is no longer stable. The developer tried optimizing the code and reducing the data size, but the issue persisted.

Resolution: It was determined that the slow performance and memory consumption were caused by the inefficient use of range objects and the repeated calculation of formulas. The team recommended refactoring the macro code to use arrays instead of range objects and to use the .Calculate method to trigger formula calculation only once. The developer made these changes to the macro code, and the performance and stability issues were resolved. The macro now runs efficiently and does not cause Excel to crash.

Get Microsoft Support for Less

Unlock Better Support & Bigger Savings

  • Save 30-50% on Microsoft Premier/Unified Support
  • 2x Faster Resolution Time + SLAs
  • All-American Microsoft-Certified Engineers
  • 24/7 Global Customer Support