Intune – App Protection Policies group assignment

Microsoft Intune’s built in feature for Mobile App Management has slight difference compared to the Azure AD Conditional Access policy assignment.

In Azure AD Conditional access, you can create policies and assign them to Distribution, Security and Office 365 groups.

That is not the case for the Intune MAM (App Protection Policies). You can only assign it to Security groups. Why the difference?

I am not sure if its a good or a bad thing.

A suggestion is to create an Azure AD Group with dynamic membership instead which applies a query instead:

Instead of assigning users to the group, a dynamic query will be made to ensure any devices (eg: iPAD Air) that tries to access corporate data will be restricted by Intune MAM policies.

Advertisements

Office 365 – Azure Information Protection V1.10.56.0

In the first few releases, this was how I had to work with customers for Azure Information Protection (AIP):

1. The organisation provides a set of document classification and labels to be used across the board
   • Public, Internal, Restricted, Secret
   • Highly sensitive documents with “Secret” labels will apply a defined set of Azure RMS protection (eg: View only)
2. IT Admin creates a global policy in AIP and assigns to all internal users
3. Internal users will need to select the respective labels when composing emails or creating any office documents
4. These data are audited and additional data loss prevention mechanisms can be put in place

Issues highlighted by IT Admins:

1. Internal users need to be able to send out documents to external parties.
2. The labels are not able to be customised with different Azure RMS protection.
3. The communication to internal users can be very difficult with regards to understanding what is Labels and Custom Azure RMS protection

This is now solved with the latest update which is version 1.10.56.0.

1. IT Admin can create a label which prompts the user to define who the intended recipient of the document is, and their rights
2. Users will comply with the organisation’s document classification policies and take ownership of any data that is sent to the intended parties

Azure Information Protection latest update is here. You can download it and try out the latest features.

Personal – Still alive

It has been 2 years since my last post and so much has changed on the cloud. That is definitely a good thing.

There are many things to talk about with regards to Office 365 and Azure solutions.

I hope i can really spend time on this blog at least on a fortnight basis.

It is time to start writing once again.

Azure – SendGrid

Before migrating to Office 365, I usually check with my clients if they have any SMTP-enabled devices or applications that require sending of email notifications to external recipients. If yes, i recommend that they check whether they are compatible with Office 365 SMTP requirements. Most of these devices usually do not meet the security requirements of Office 365 but we still need a proper workaround. Hence, I usually recommend to configure an IIS server with SMTP relay service.

Most clients who are already on Office 365 are now exploring the feasibility of moving some of their server workloads to cloud, and looking at Microsoft Azure for their IaaS. They also want to know if they can move their SMTP relay server to Azure. Technically, the answer is yes but I do not recommend it due to security concerns with regards to the cloudapp URL assigned to it.

The alternative is to use SendGrid! You can check them out. It’s actually a paid service but if your organisation sends less than 25,000 emails a month, its basically free. For most clients, it is good enough. Follow the guide below to set up and test.

Pre-Requisites

1. Office 365 Exchange Online account
2. Microsoft Azure Subscription

Procedures

1. Log on to Microsoft Azure. Click on New and select MarketPlace.
   
2. Select the SendGrid app and give it a name. 
3. Once done, complete the wizard by clicking on purchase. You can see that it is free. I am not sure if you can create multiple SendGrid app and then use that for individual devices or apps. Sounds like a grey area there.
   
4. The SendGrid app will be provisioned to the Azure subscription.
   
5. Click on the Connection Info to review the smtp server details, along with the unique username and password. You will require this to authenticate with the SendGrip app before relaying emails.
   
6. Let’s test the smtp relay. I prefer to use PowerShell but you can use any other tools like Telnet. You have to change the variables. Note that the $EmailFrom address should be coming from
   $Username =”azure_cb749bfeb03c****************@azure.com“
   $Password = ConvertTo-SecureString ‘*****************’ -AsPlainText -Force
   $credential = New-Object System.Management.Automation.PSCredential $Username, $Password

   $SMTPServer = “smtp.sendgrid.net“
   $EmailFrom = “smtpservice@domain.com“
   $EmailTo = “shahaizan@domain.com“
   $Subject = “SendGrid test“
   $Body = “SendGrid testing successful“

   Send-MailMessage -smtpServer $SMTPServer -Credential $credential `
   -Usessl -Port 587 -from $EmailFrom -to $EmailTo -subject $Subject -Body $Body

That’s all there is to it. I do have a big concern though, especially on the usage of the “Email From” address. It seems i can use any email address from any domains and i will still receive it at my test account, whether junk or not. I need to discuss on this with my peers.

Office 365 – PST Import Service

Pre-Requisites

1. Office 365 Admin with Mailbox Import Export Admin role
2. Azure AzCopy tool
3. PST file
4. ‘PST to User’ mapping file (CSV)
5. Exchange Online mailbox

Procedures:

1. Logon to Office 365 Admin Center. Import>Upload files over the network
   

2. Download the Azure AzCopy tool and install it.
   
   

3. Copy the secure storage account key and secure network upload key
   
   

4. Run the Microsoft Azure Storage CommandLine
   
   

5. Run the command:
   azcopy /source:\\SG-SJAMAL\O365_PSTimport /dest:https://f28e97c60cdc47138b56c2c.blob.core.windows.net/ingestiondata/SG-SJAMAL/O365_PSTimport /destkey:RfJP18qtfyTQAvM3AwNkB2zylUzd5I9USCJqZ5Y9pUZG/f06g9rskmqz24yLkqfc/hQzjqZWdhJL/1VVFB/fIw== /S /V:C:\PSTUpload\Uploadlog.log
   
   

6. Create a PST Mapping file and save to CSV
   
   

7. Once completed, click next.
   
   

8. Create a backup job name
   
   

9. Upload the PST Mapping file
   
10. Verify the status of the import
    

DirSync – Error 0x80005000

Issue:

1. During installation, DirSync application encountered error 0x80005000
2. Running installation as administrator was not successful

Investigation:

1. Seems that there are other Domain Controllers and child domains in different subnets
2. And the DirSync server belongs to a subnet which is not able to communicate with the other DCs in other subnets
3. Running the script below identifies all the DCs that is not able to be communicated:
   

   ---

   $domains = ([system.directoryservices.activedirectory.forest]::GetCurrentForest()).domains

   foreach ($domain in $domains){

   @”

   `n

   ===================================

   Identifying Domain Controllers for: $domain

   ===================================

   `n

   “@

   $domain.findalldiscoverabledomaincontrollers()

   }

   ---

Resolution:

1. Ensure the firewall and network communications allow the existing DirSync server to communicate with all DCs and child domains in the environment
2. Once the network limitation is lifted, retry the DirSync installation and it should pass through

DirSync – Duplicate AD objects on-premises

Issue:

1. Some AD users are not able to sync to Office 365
2. Problem was due to a previous case of corrupted Domain Controller
3. The accounts on Office 365 somehow is taking sync from the AD Objects of the corrupted DC

Investigation:

1. PowerShell was used to retrieve the ObjectGUID for the affected accounts and compared against the Office 365 accounts
2. It is confirmed that the ObjectGUID did not match

Resolution:

1. Configure the DirSync Active Directory management agent to stop sync for the affected users (OU or Attribute based filtering)
2. Perform a Full Sync
3. In Office 365, run a PowerShell script to delete the affected accounts, now a Cloud user instead of Synced user
4. In Office 365 Deleted User list, run a PowerShell script to purge the deleted accounts
5. Configure the DirSync AD agent again to include the affected users
6. Perform a Full Sync
7. Perform a comparison with Office 365 and AD using the ImmutableID attribute.

The ImmutableID must match AD and Office 365 and the accounts should now be able to sync properly.

Office 365 – Hybrid license automation

I simply love PowerShell for it’s ability to solve redundant tasks for my projects. One of the scripts i worked on was to check on the migration status for each mailbox before assigning a license in Office 365. I scheduled the script to run every 1 hour, daily.

The script basically performs the following:

1. Get all the existing mailbox move requests in Office 365
2. Check the migration move status
3. If status completed, check for license assignment
4. If licenses is assigned, ignore the account
5. If licenses not yet assigned, assign the license
6. Send an email report on the script completion
7. Send an email report on the migration move status

The important variable here is the license which you need to define by using the Get-MsolAccountSKU cmdlet. Now for this script, I based on the operational requirement that the user need to have a license assigned once migration is completed. I am not able to be on standby 24 hours a day, so at the very least the user should be able to login to a valid mailbox in Office 365. I can reassign another exchange license to him later on.

You can email me for the script (shahaizan.jamal@gmail.com), i will be glad to share it.

Update:

You can now download it here: https://gallery.technet.microsoft.com/scriptcenter/Exchange-Hybrid-License-c626454e

PowerShell – Convert X500 Address

Sometimes we get a delivery failure due to the Legacy Exchange DN or X500 address. An example below:

Delivery has failed to these recipients or groups:

MIS SINGAPORE
The e-mail address you entered couldn’t be found. Please check the recipient’s e-mail address and try to resend the message. If the problem continues, please contact your helpdesk.

Diagnostic information for administrators:

Generating server: Server.domain.local

IMCEAEX-_O=SG+20DOMAIN+20EXCHANGE_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+
28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=MIS+20SINGAPORE@domain.local

#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

I wrote a simple script to convert these into a proper X500 address, which can then be added to the affected user’s proxy address. All you need to do is copy the IMCEAEX error value into the $X500Source variable below. The resulting $X500 variable will then be used to resolve the issue in Exchange.

# Define the Legacy Exchange DN here
$X500Source = “IMCEAEX-_O=SG+20Domain+20EXCHANGE_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+
28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=MIS+20SINGAPORE@domain.local”

# Converts the various strings to the proper syntax
$X500 = $X500Source.Replace(“_”, “/”)
$X500 = $X500.Replace(“+20″, ” “)
$X500 = $X500.Replace(“IMCEAEX-“, “”)
$X500 = $X500.Replace(“+28”, “(“)
$X500 = $X500.Replace(“+29”, “)”)
$X500 = $X500.Replace(“+2E”, “.”)
$X500 = $X500.Replace(“+5F”, “_”)
$X500 = $X500.Replace(“@apcprd06.prod.outlook.com”, “”)

Write-Host $X500

PowerShell – Connect Exchange Online & MSOL

It has been a while since the last post. I have a few articles archived in my OneNote for publishing, hopefully that goes out in this few weeks. I have decided to post some of my daily PowerShell scripts here so that you can use it to aid your deployments. My preferred choice of PowerShell app is still PowerGUI because of the interface. Do check it out if you want a good PowerShell editor. Free of course!

I used this script to easily connect to Office 365 Exchange Online and MSOL.

#Define the Office 365 Global Admin Username and Password

$Username =”username@domain.com.sg”
$Password = ConvertTo-SecureString ‘password123’ -AsPlainText -Force

#Populate the credential with $Username and $Password

$Livecred = New-Object System.Management.Automation.PSCredential $Username, $Password
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber

#Import MSOL cmdlets and  Connect to Office 365 MSOL

Import-Module MSOnline
Connect-MsolService -Credential $Livecred