Issue with opening AIP/MIP Protected PDF Documents in Microsoft Edge

Over the past few weeks, I have been doing my own deep dive study into MIP/AIP. I was looking at the following article:

Which PDF readers are supported for protected PDFs?

This article said that the later versions of the Edge Browser should natively be able to open and view MIP UL Protected PDF documents:


So I proceeded to do a Edge browser check on my Windows 10 test machine:

Approved Version 86 of Edge

Great! I should be able to protect a PDF file as Confidential, and then be able to open it in Edge with no other software required.

This was NOT the case.

I protected the PDF:

File set to Confidential Label

I waited a few minutes and then tried to open the file. I received the following error:

I received a permissions error and not the standard blocking error

Another issue with this error is that I did not receive the standard issued AIP Protection error that you should get like you would when opening a protected document without the proper plug-in with Adobe Reader:

The error in Edge said to check ownership permissions, which I did:

Amy C. Carlson is my test user for this scenario.

I could also go back into the AIP/MIP client and remove the Confidential label from the file. So, I was puzzled at this point. I then proceeded to install Adobe Reader DC and the AIP Plug-In as described in the original article.

Download MIP Adobe Plug-In

Once that was completed, I was able to logon as the account, open the document in Adobe Reader DC AND in Edge.

File opened successfully after installing the plug-in

According to the article, you should not need the plug in or any other product to open the protected file in Edge after protection is applied. Has anyone else experienced this issue and can explain why the article is not doing as said. I would love to hear any answers you may have on this subject!

PLEASE COMMENT!
THANK YOU FOR READING!

REFERENCES:
Which PDF readers are supported for protected PDFs?
MIP plug-in for Acrobat and Acrobat Reader 
Azure Information Protection Reader

RBAC Role Assignments NOT installed during Exchange Directory Preparation

I had a very interesting installation issue recently when installing Exchange 2019 into a new environment. We ran through all the Exchange Preparation for the root and child domains in the forest as described HERE. The results of those installation procedures showed SUCCESS, but when we started installing Exchange, we ran into issues with the System Mailboxes not being available to complete the Mailbox Role part of the installation. Most of the articles that I found said to re-run the Domain Prep (/preparealldomains) and the AD Prep (/pad). So we did, and managed to get the first server installed somehow.

The reason I said somehow is because when we tried to logon to the EAC, we would get a 400 Bad Request Error and could not logon to the console. Next, we tried PowerShell and was able to load PowerShell, but I noticed that only ~100 cmdlets loaded. I thought that maybe we had to re-create the account mailbox to get it working properly. Problem was, one of the cmdlets that would not load was Disable-Mailbox along with others like Enable-Mailbox and New-Mailbox. It was as if the admin account we were using had no rights to administer Exchange in any way.

Next, we opened the mailbox in OWA. The mailbox came up okay, so I told the admin to change the URL to /ecp to try and get into the admin center. What happened was that the normal user control panel opened instead, showing again that the account did not have permissions.

We checked replication to the child domain and made sure there were not any apparent AD issues present. There were none. I next started reviewing how Exchange uses RBAC (Role Based Access Control) Groups and Role Assignments to grant users access to Exchange Admin Functionality. I read the following article located HERE.

Something told me to go and check the Schema again, so I went to ADSIEdit > Configuration Container > Services > Microsoft Exchange > (Organization Name) > RBAC > Role Assignments

I looked at the list of role assignments in the window as follows:

Small List of RBAC Role Assignments
RBAC Role Assignments Missing Objects

From the picture, you can see that the list is small, which in my experience is not correct. I verified this by going into my own 2019 environment and comparing the number of objects in that folder:

RBAC Assignments Object list with CORRECT Objects Listed

If you notice the list is MUCH longer and has many more objects listed in the container. So, how did Exchange Setup miss this during preparation? That I will find out later, but first I have to remediate this problem.

CAUSE:

If the RBAC roles assignments are not installed to allow an account to have administrative privileges in Exchange, then you cannot administrate Exchange to even make the necessary changes! Especially so if you’ve only installed ONE server in the environment!

REMEDIATION:

Manually repair the installation by running the script that creates these Objects in the Schema during setup.

******DISCLAIMER: Running the following commands in these instructions, running ADSIEdit, and/or making changes to your Schema and Exchange Installation outside the normal setup process is NOT recommended! Microsoft, LDLNET LLC, nor I (Lance Lingerfelt) are responsible for any issues or errors that may arise from using these instructions, period!******

That said, preform the following to regenerate the objects in the Schema:

1) Open Windows PowerShell (not the Exchange Management Shell) on the server that you installed Exchange Server on with the same account you used to install Exchange.

a. If you have UAC enabled, right click Windows PowerShell and click Run as administrator.

2) Run Start-Transcript c:\RBAC.txt and press Enter

a. This will start logging all commands and output you type to a text file.

3) Run Add-PSSnapin *setup and press Enter

a. This adds the setup snap-in which contains the setup cmdlets used by Exchange during install. You may see errors about loading a format data file. You can ignore those errors.
NOTE: DO NOT run any other cmdlets in this snap-in. Doing so could irreparably damage your Exchange installation.

4) Run Install-CannedRbacRoleAssignments -InvocationMode Install -Verbose and press Enter.

a. This cmdlet should create the required role assignments between the role groups and roles that should have been created during setup.

b. Be sure you run with the Verbose switch so we can capture what the cmdlet does.

5) Run Remove-PSSnapin *setup and press Enter

6) Run $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://servername/PowerShell/ -Authentication Kerberos and press Enter

a. Be sure to replace SERVERNAME with the FQDN of your server.

7) Run Import-PSSession $Session and press Enter

a. You should notice that the normal number of cmdlets load (~700)

8) Run Get-ManagementRoleAssignment and press Enter. If you are able to run the cmdlet, then the remedation worked.

9) Run Stop-Transcript and press Enter

The final check is to return to ADSIEdit and check the container and see if all the objects are there. We also were now able to get into EAC as well as saw that the Arbitration mailboxes were populating along with the Health Mailboxes as needed per the installation.
It was very neat to see how running the Add-PSSnapIn cmdlet opened all the scripts from the Exchange Setup and allowed me to manually fix the installation problem by running the cmdlet script that need to perform that task that setup missed or refused to run.

POST MORTEM REVIEW

I am going to look over the installation logs and see where the installation failed and try to find out why it did not run on the subsequent re-installations of the AD Prep and Domain Prep. I will post those finding in this article when I have that available.
Thanks again to my Microsoft and Trimax teammates for your assistance with this. It has helped the customer in more ways than one!

HAPPY TROUBLESHOOTING!
POSITIVE ATTITUDE YIELDS POSITIVE RESULTS!

Unable to open settings from the Settings App in Windows Server 2016/2019

In Windows Server 2016/2019 you have been upgraded to the Windows 10 Desktop Experience GUI. So, in the new versions, you are directed to use the Gear Box in Windows to get to your settings. What was happening within the Settings is that I would choose a setting that calls on the control.exe file to open a Control Panel app. I would get the following error when attempting to do that function:

Permission Denied to Open a CPL Applet through control.exe

I immediately think it is a permissions issue. So I go to try to validate the permissions so that I could change them. Turns out, that due to it being a Windows System directory, I couldn’t modify the permissions without compromising directory security with NTFS permissions:

The options are all greyed out for the directory on purpose

Now, if I open Control Panel, Network Sharing Center, etc…, I was able to access the applets with no issues. This was just happening in the Settings Gear Box Application. So, I started looking around and found that there is a registry key that needs to be modified so that your Administrator account can open these settings apps through the Settings Application:

1) Launch the Registry Editor (regedit.exe)
2) Navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

3) Change the value of FilterAdministratorToken (REG_DWORD) from 0 to 1 (If you don’t see that key, you can create it by right-clicking on any empty space from the right panel and select New > DWORD value, type the name and set the value to 1)
4) Reboot the computer and then it will be working fine.

I decided to create a Group Policy in AD to add this registry key so that it would propagate to all my 2016/2019 Servers:

1) Launch the Group Policy Manager
2) Create a new GPO and Link it to your Domain
3) Go to Computer Configuration > Preferences > Windows Settings > Registry > New Registry Key (DWORD)
4) Set the Action to “Replace”
5) Set the path as:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
6) Set the Key as FilterAdministratorToken
7) Set the Value as 1 (Decimal Format) and Save
8) Run gpupdate /force on your servers.
9) Schedule a Reboot of those servers for the change to truly take effect.

GPO Settings

After the reboot of the server, all the apps launched correctly from the Settings Application within Windows. I am going to research a little more to see why this is like that. If you have a comment, or more information, please feel free to post!

HAPPY TROUBLESHOOTING!
PLEASE COMMENT!