Recently, I was trying to perform an audit search on an Office365 organization and found auditing wasn’t enabled. When I tried to do it straight from the audit screen, I encountered this error:
Sorry! We couldn’t update your organization settings. Please try again.
I went straight to PowerShell and ran Get-AdminAuditLogConfig | FL Unified* and it was not enabled.
To resolve this, I ran Enable-OrganizationCustomization
And then I ran the Powershell command Set-AdminAuditLogConfig – UnifiedAuditLogIngestionEnabled $true
We’re going to be using the Get-InboxRule commandlet. If you run it outright, you’ll see a limited list of Inbox rules across your tenant. To narrow things down, you can use Get-InboxRule -Mailbox [user] to get rules for a specific user. Using the -Identity parameter will not work for this! Identity is for specifying specific Inbox rules. You can use wildcards, so you could do Get-InboxRule -Mailbox jeff*
The results will be:
From here, you can use the -Identity parameter to get information on specific rules such as their date of creation, what they actually do, and more!
A client of ours wanted to upgrade their Windows 10 Professional licenses to Windows 10 Enterprise by way of E5 licensing in Office365 / Azure Active Directory.
Most computers worked fine, but a few just didn’t work and upgrade as they should have. There isn’t a lot of documentation on this, so I thought I’d put out there what worked for us and what we found. I ended up opening a ticket with Microsoft Escalated Support and worked with a rep over a few weeks.
First and foremost, make sure in Office365 that the E5 license has the option checked off for Windows 10 Enterprise.
First Troubleshooting Recommendation: dsregcmd
Run dsregcmd /status on the affected machine as the logged in user (and not a System or admin account).
If WamDefaultSet : ERROR and / or AzureAdPrt : NO are found, these would indicate an issue on Azure’s end. You want to see both answered with YES. These fields indicate whether the user has successfully authenticated to Azure AD when signing in to the device.
If the values are NO, it could be due to:
Bad storage key in the TPM associated with the device upon registration (check the KeySignTest while running elevated).
Something on my list of things to do has been to update SAML roles for an application setup a few years ago before Microsoft simplified certain aspects of SAML applications. After tickets with Microsoft support that ended up escalated but with no assistance from them, I found that these roles could be updated via Microsoft Graph. Let’s dive in.
I have my application ID and have requested the body via GET below and the URL https://graph.microsoft.com/beta/servicePrincipals/{ID}(without the curly brackets surrounding your ID)
In the JSON Response Preview, you can see the appRoles listed for the application. After using my Google-FU and not finding any documentation on this at all, I experimented and after trial and error, figured out how to update the approles while keeping existing appRoles.
First, you’ll need a unique GUID for the new approle. In Powershell, you can run new-guid to generate a new GUID for your new approle(s).
Next, copy your entire existing Approle digest from the Response Preview to your editor of choice; I like Visual Studio Code. This means everything from the approles: [ line to the bracket at the end of the last role.
Add a new approle (you can copy a previously used one), paste in your GUID, and change the description, displayname, and value. Because this is JSON, you’ll need to add a comma to the curly bracket for the previous approle.
Once you’re done editing your approles, go back to Microsoft Graph. Where before you chosen to GET , now select PATCH. Keep the URL the same.
Be sure to validate the JSON (you may need to add curly brackets to the beginning and end of the JSON file) using any free online tool or Visual Studio Code. Paste the JSON code in to the Request Body in Microsoft Graph and hit Run Query.
If everything went well, you should see a green OK!
I recently wrote about Microsoft’s new Powershell V2 Module and locating IMAP and POP enabled mailboxes using it. Now we’re going to get to disabling IMAP and POP to keep things secure! As of the date of this post (January, 2020) there are no new V2 modules to Set-CASMailbox, so we’ll have to use a V1 command. This will disable IMAP and POP across the tenant:
Microsoft recently released a preview of their new Exchange Online Powershell module. One of the highlights is that it has built-in support for MFA-enabled admin accounts. One of my biggest pet peeves was that Microsoft made you jump through hoops and poorly supported MFA with their V1 module.
To get started, install the module from the Powershell gallery via
Install-Module -Name ExchangeOnlineManagement
Note only Powershell 5 is supported, with Powershell Core and 7 support coming… soon.
The commands have changed too. Get-Mailbox is still able to be run, but the new command is Get-EXOMailbox, which yields output more efficiently then its predecessor according to Microsoft, by changing what properties get shown and not including blank properties.
You can now connect via “Connect-ExchangeOnline” which creates an MFA-capable prompt. After you sign-in, you’re shown the new cmdlets!
I wrote this quick and dirty one-liner to help monitor and find stuck emails in Exchange / Office365 mailboxes across a tenant and export the list as a CSV.
I recently enabled Azure Active Directory (AD) Connect and wanted to turn this feature on. After doing some reading, I found a simple way to enable the AD Recycle Bin.
In the management console, go to Tools > Active Directory Administrative Center
Select Local Domain and in the Tasks Pane
Select Enable Recycle Bin.
Click OK
NOTE: Be aware this feature cannot be disabled.
Click OK. Once enabled, wait for AD replication to complete as this is a change made on the configuration partition. This process may take a while should your organization have a large active directory infrastructure.
A very simple enablement of a process that could save you hours of restore time. Again, this process cannot be reversed once invoked.
Had an odd one today. An internal user with permissions to a Sharepoint site was getting the error “user not in directory”. Searching Google comes up with many different options and reasons for this error, but no concise cause / solution.
The user was able to login to Office365 webmail normally without any errors and was had a Sharepoint license for several weeks and hadn’t reset their password recently.
Eventually, I had the user un-invited and then re-invited and it worked!