Test Layout

Most of the time in a Windows environment, a Windows PowerShell script runs in the security context of the user account that is running it. If you have a scheduled task that runs a PowerShell script then you can specify a user account (service account) that is used to run the task. The service account needs to be assigned the necessary permissions to perform any actions in the script. In some cases, you need to script to access remote resources and sign in. For example, if you have a scheduled task that pulls reporting information from Office 365. PowerShell has a method for storing encrypted credentials that can only be accessed the user account that stored them. The code below prompts you for a credential and then stored is encrypted in an XML file. $credential = Get-Credential $credential | Export-CliXml D:\credential.xml To retrieve the credential and using it within a script, you read it from the XML file: $credential = Import-CliXml D:\credential.xml If you created the XML file w...

A key part of most Office 365 deployments is directory synchronization with on-premises Active Directory (AD). To maintain a link between individual object in AD and Office 365, one attribute in AD is defined as the source anchor. The source anchor acts as a unique identifier for each object so that you can change properties like UPN and have them replicate to the proper matching object in Office 365. Older versions of Azure AD Connect used the objectGUID attribute as the source anchor. In many cases, this is a good choice because it is an attribute that doesn't change. However, in complex configurations with multiple AD forests, this can cause an issue during migrations. When a user account is moved from one AD forest to another, it gets a new objectGUID in the new forest. Due to the new objectGUID , Azure AD Connect treats the user as a new user instead of an existing user. To avoid this issue, we need to use an attribute for source anchor that can be moved between forests. Micro...

A client has an issue in their Office 365 tenant that started yesterday (March 12/18). When attempting to delete a mobile device linked to a user, it fails and gives the following message: Error on proxy command "Remove-MobileDevice -Identity:' DeviceName ' -Confirm:$false to server...the mobile device DeviceName cannot be found... Error when removing mobile device I was still able to remove the device by using a Windows PowerShell prompt connected to Exchange Online. But what I noticed is that for the Remove-MobileDevice cmdlet to work, I needed to use the Identity property from the mobile device rather than the Name property that the Exchange admin portal was attempting to use. Using Windows PowerShell to remove the mobile device You can see in the screenshot above using the Name or DeviceID properties didn't work. Only the Identity property which includes the full path with the user name works. I've opened a support ticket with Microsoft and we'll see what ...

One of the simplest things you can do to prevent malware from spreading through email in Office 365 is blocking attachment types that are commonly used to send malware. This includes executables (.exe), scripts (.vbs), and macro enabled office documents (.docm). The anti-malware policies in Office 365 have a setting Common Attachment Types Filter that is off by default. I definitely recommend that you turn it on. When you turn it on, the following file types are blocked by default: ace ani app docm exe jar reg scr vbe vbs Office 365 has an existing list of many other file types that you can add, but in Exchange admin center, there is no method to add your own customized file types. For example, xlsm (Excel macros) is not in the list. You can add your own customized file types by using Windows PowerShell in Exchange Online. To add your own customized file types to the malware policy, you can use the Set-MalwareFilterPolicy cmdlet. The general process is as follows: Retrieve the existi...

In Office 365 or Exchange Server 2013/2016, you can use the administration console to view information about migration batches. To find out information about failing moves, you can view the details of the migration batch and then view the report for individual mailboxes. When you view the report for a mailbox a text file is downloaded for viewing. The report provides detailed information about how much data has been downloaded. Also, if there are errors, they are contained in the report. Unfortunately sometimes the errors are pretty generic. For example, one error I got recently was: Transient error TimeoutErrorTransientException has occurred. The system will retry (200/1300). Instructions on how to review the report: https://technet.microsoft.com/en-us/library/jj898491(v=exchg.150).aspx Since the error was happening often, we needed to get more information. Fortunately that detail is available, but not in that report. Instead, you need to use Windows PowerShell to view the move reques...

I ran into an issue today where I needed to remove a proxy address from a cloud-based administrative user in Office 365 that was unlicensed. This user had a proxy address that was conflicting with a proxy address that was being synced with Azure AD Connect for another user account. The cloud user was originally created as byron@OnPremDomain.com and renamed to be byron@CloudDom.onmicrosoft.com. When this was done, the original address (byron@OnPremDomain.com) was kept as a proxy address. You could view both addresses when using Get-MsolUser. This address caused a synchronization error for an on-premises user named byron@OnPremDomain.com. To resolve this error, I need to remove byron@OnPremDomain.com from the list of proxy addresses. However, you can't do this with Set-MsolUser. The mechanism for managing proxy addresses in Office 365 is Set-Mailbox. But, without a license, there is no mailbox for the user account. The solution is to add a license temporarily: Add a license for byron...