We deployed the Cloud App Discovery Agent to a number of test systems in our IT department, and while we got good feedback, we deployed before it was made obvious that the Deep Packet Inspection feature installed a custom Root CA in each workstation's Trusted Root Authority store. The name on that cert was a random FQDN from our tenant, and confused the heck out of us when we tried to delete what we thought was an unknown cert. We've also found issues when using Cisco's Cloud Web Security suite wherein the custom Root CA was causing problems with the Cisco agent and the Cisco software would declare all websites you visited as "untrusted". We've got a Premier case open, but thought we would leave feedback here as well that perhaps the "Deep Packet" feature shouldn't be the default option when deploying the client.

I just went through a living nightmare with an orphaned VSO application in one of my AAD directories that was preventing me from deleting the directory. The VSO system wasn't letting me have access to the VSO instance. I couldn't reach it via https://<account>.visualstudio.com; and although I could see the instance at http://www.visualstudio.com, that portal wouldn't let me delete the VSO instance.

The original Azure subscription where the VSO account was connected was deleted. The VSO instance was still connected in my regular Azure AAD ... in a directory with nothing else in it and no users other than the Azure global admin. I couldn't get rid of the VSO app.

I made two support requests to Azure Support for help, and one made it to their Escalation Dept. ... no dice! Even they didn't know how to disconnect or delete the VSO app in that directory. Searching around online and through trial-and-error, I was able to work it out. Look the **** you have to go through, then I have a feature request for the Azure Portal.

Here we go ...

Setup:
In my Azure Active Directory directory list there was a directory (we'll call it Contoso Online) that has a VSO application instance attached to it that was preventing me from deleting the Contoso Online directory. No attempts to delete the VSO account or detach it from AAD were successful.

[Note that this will require Windows PowerShell and that the Windows PowerShell Engine 2.0 must be activated in Windows Features on the PC. Some online references called for having .NET 3.5 installed, but I was able to get this to work without .NET 3.5, probably because I'm using a late version of PowerShell. These steps worked on my Win10 box.]

1. Create a global admin account (admin@contosoonlineoutlook.onmicrosoft.com) in the Contoso Online directory. Login to the Azure Portal with the account and change the temporary password. Logout of the Azure Portal.

2. Download and install the Microsoft Online Services Sign-In Assistant for IT Professionals from http://www.microsoft.com/en-us/download/details.aspx?id=28177

3. Restart the PC

4. Download and install the Azure Active Directory Module for Windows PowerShell BETA version from https://www.microsoft.com/en-us/download/details.aspx?id=39267 ... Note that you cannot use the non-BETA version. It doesn't work. Only the BETA version will install. Note that both the BETA version and the non-BETA version have the same version number: 7.250.4551.0, but only the BETA version will work for some reason.

5. Open Windows PowerShell. Execute command ...

Connect-MsolService

Supply the global admin credentials (admin@contosoonlineoutlook.onmicrosoft.com) and password.

6. Execute command ...

Get-MsolServicePrincipal | Remove-MsolServicePrincipal

... and bunch of red exceptions will appear. Ignore the exceptions. Close the PowerShell window.

7. Sign back into the Azure portal with your normal global admin account (not the one created earlier ... use your normal global admin account). The VSO application is now GONE from the directory.

8. Go to the Users area of the directory and delete the global admin account setup for this process (admin@contosoonlineoutlook.onmicrosoft.com).

9. Go back to the AAD list. Select and (FINALLY!) delete the directory (Contoso Online).

Good grief! I really hope this gets worked out. Basically, the steps above drop the Service Principal of the directory. I think what that does is break any connections to external applications.

Feature Request: We really need this in the portal somehow. There should be some sort of "Drop Applications" button or process or wizard. Keep in mind that even Azure Support personnel don't seem to know how to handle this problem.