Tuesday, March 13, 2018

O365 Removing Mobile Device Fails in Portal

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 they come back with. It was not a know issue when I contacted them, but they're going to do some checking on the back end. I will update this blog post when there is a resolution.

UPDATE: March 14/18
So, support indicates that it's definitely an issue, but to raise visibility with the support team they asked me to create an "idea" at office365.uservoice.com. This location seems more for feature requests than bug fixes. However, I've put an "idea" in. I'll continue to update as I learn more.

If you are also experiencing this issue and want to raise its visibility, go to this link and vote it up:

Saturday, January 27, 2018

Outlook on the web offline access failure

There is a bug in Exchange Server 2016 CU6, CU7, and CU8 that prevents clients from using offline access for Outlook on the web. It was working properly in CU5.

In CU5, in Options, you select Turn on offline access and then another window pane is shown that asks whether you have exclusive use of the computer or not. In CU8 (also CU6 and CU7), that pane appears very quickly and then goes away. Basically the text flickers but it is removed right away. You can see a video of this behavior below.

I tested this with Internet Explorer, Edge, Firefox, and Chrome with consistent results. I also tested this using both Windows 10 and Windows Server 2016 as the client operating systems.

After trying everything I could think of for testing, I posted this issue to the Microsoft support forums and they confirmed that this is a bug and will be fixed in a future update.

Wednesday, January 24, 2018

Install-AntispamAgents.ps1 Fails for Exchange 2016 CU7 and CU8

Not many organizations enable the antispam agents on their Exchange servers since they're probably paying for an additional service to do spam filtering. However, if you attempt to enable it on Exchange Server 2016 CU7 or CU8, there is an error in the script that you need to run. As of right now, CU8 is the latest update available so, this may continue in later updates.

To enable the antispam agents in Exchange Server 2016, you run the Install-AntispamAgents.ps1 script located in C:\Program Files\Microsoft\Exchange Server\V15\Scripts. However in CU7 and CU8, you get an error like this:
There are several screens of error information, but the key part is:
A parameter cannot be found that matches parameter name 'EscalationTeam'.
If you open the script and go to line 50, you'll see the following at the end of the line:
If you delete the following text from that line, the script works properly:
-EscalationTeam "AntiSpam";
Please note that this script does have a digital signature. Editing the script invalidates the digital signature. So, to run this script ensure that your execution policy is not set to AllSigned. It will run fine with execution policy set to either Unrestricted or RemoteSigned.

Monday, January 22, 2018

All Certificate Names MUST be in Subject Alternative Names

This has been popping up for a while, but it's worth pointing out again. When you get a SAN/UCC certificate, the DNS name that you use for the subject (common name) also needs to be in the subject alternative names attribute.

For example:
  • Subject:
    • webmail.contoso.com
  • Subject alternative names
    • webmail.contoso.com
    • exch1.contoso.com
    • exch2.contoso.com
    • Autodiscover.contoso.com
When you get your certificate from a public certificate authority (CA), most of them ensure that the subject is also added as a subject alternative name. However, some might not and you should watch for it.

It's important to note that the Microsoft CA does not automatically add the subject to the list of subject alternative names. So, make sure that you do it as part of your certificate request for your internal CA.

The reason you need to do this is because of how web browsers are processing subject alternative names. Web browsers are ignoring the subject if a list of subject alternative names is present. All web browsers seem to be enforcing this now. A few years ago, the web browsers would process both the subject and the subject alternative names.

Here's the quote from RFC 2818 from May 2000 (yes, that long ago):
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

As a slightly interesting side note. The subject field is optional when SANs are defined. However, some older software might still require the subject to be defined.

If you are configuring certificates in Exchange server, be aware that the Exchange admin console (EAC) does not properly differentiate between subject and subject alternative names. In the certificate shown below, webmail.adatum.com is in the subject and not in subject alternative names. EAC (Exchange 2016 CU8) is including the subject in the Subject Alternative Names box which can be misleading.


Tuesday, December 19, 2017

PowerShell cmdlet to query .NET Framework version

Whenever I'm doing new installs of Exchange, I'm annoyed when I need to figure out the .NET Framework version installed based on registry keys. You can see the documentation here:
 Just like the bad infomercial says: "There's got to be a better way!"

This has bothered me for sometime and I considered writing a small script to query and display the version. Then I thought...that would be good if I put it in the PowerShell Gallery so that I could easily access it from anywhere. Then I thought...I'm probably not the first person to have this idea.

In the PowerShell gallery, Joakim Borger Svendsen has been kind enough to create this for us as a module named DotNetVersionLister. He's also kind enough to keep it updated. There have been seven releases in 2017.

On a computer that has Internet access, you can install directly from the PowerShell Gallery:
Install-Module DotNetVersionLister
You can also save it to file for distribution to computers that don't have Internet access by using:
Save-Module DotNetVersionLister -Path C:\Temp
After you install the module, you have a single cmdlet named Get-DotNetVersion. This cmdlet is quite flexible and allows you to query the .NET Framework version from the local computer and remote systems. For remote systems, it can query the information using remote registry access or PowerShell remoting. So, it's flexible depending on your configuration.

Query the .NET Framework version from the local computer:
Get-DotNetVersion -LocalHost
Query the .NET Framework version from a remote computer via remote registry:
Get-DotNetVersion -ComputerName Exch01
Query the .NET Framework version from a remote computer via PowerShell remoting:
Get-DotNetVersion -ComputerName Exch01 -PSRemoting

Related links:

Tuesday, December 12, 2017

Docker Fails to Start on Reboot

For the last couple of weeks I've been working with Windows containers using Docker. I ran into a severe problem with the networking. I created a transparent network on the host and rebooted. After reboot, the docker service wouldn't start and had the following error in the event logs:
Log Name:      Application
Source:        docker
Event ID:      4
Task Category: None
Level:         Error
Error starting daemon: Error initializing network controller: error obtaining controller instance: failed to get endpoints from store: failed to decode endpoint IPv4 address () after json unmarshal: invalid CIDR address:
My first fix for this issue was to delete the following file:
  • C:\ProgramData\docker\network\files\local-kv.db
After this file was deleted, I was able to start the Docker service and it stayed running. That file was recreated when the docker service started and I was able to run docker commands.
Running docker network ls showed me that a transparent network I had created just before the restart was broken. That network was renamed a long random string. At this point, I could delete the randomly named transparent network, but a new one came back after each restart of either the Docker service or the host.

The final fix to stop that recurrence was running:

.\WindowsContainerNetworking-LoggingAndCleanupAide.ps1 -Cleanup -ForceDeleteAllSwitches

That script is provided by Microsoft on GitHub here:
It's also worth noting that others are also having this issue:

Thursday, September 28, 2017

Customizing File Types for Common Attachment Types Filter

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:
  1. Retrieve the existing list of file types in an array.
  2. Add the new file types to the array.
  3. Set the file types for the malware policy by using the array

 $FileTypesAdd = Get-MalwareFilterPolicy -Identity Default | Select-Object -Expand FileTypes  
 $FileTypesAdd += "xlsm","pptm"  
 Set-MalwareFilterPolicy -Identity Default -EnableFileFilter $true -FileTypes $FileTypesAdd  

Note that when you run Set-MalwareFilterPolicy, you will probably get an error indicating that you need to run Enable-OrganizationCustomization. This creates additional objects in your Exchange Online tenant that allow additional customizations like this one.

After you have added the file types to the policy, they are visible in Exchange admin center. You can modify the the list of file types in Exchange admin center after this point, and it does not accidentally remove the customized file types you added.

Another way to accomplish this same goal is by using transport rules. Create a rule to apply if Any attachment's file extension matches. And then Redirect the message to hosted quarantine. However, this does not give the same options for notifications as using the malware policy. You could probably build the same functionality into the rule if you add enough actions, but I think it's easier to have one central location that controls all of the malware rather than adding rules.

Additional resources: