Tuesday, January 17, 2017

O365: Unable to Create Distribution Group

Microsoft is aggressively encouraging Office 365 customers to use Office 365 groups instead of traditional distribution groups. In the Exchange admin center, when you select to create a distribution group, you get a popup to create an Office 365 group instead, as shown below.

There is one difference between this popup and if you actually selected an Office 365 group. This window has an option to create a distribution list. You can see it in the screenshot above by the red arrow. I'm pointing out that option because I didn't see it at first and was only made aware of it by Microsoft.

I should also note that another work around is to create a distribution list in the Office 365 admin center. That option is still available and is the same as creating a distribution group in Exchange admin center.

Sunday, January 15, 2017

Office 365 Tech Support is Good!

As a technology professional, I dread calling tech support sometimes. Most of the time when you contact tech support (for any software), you get a front line person that is not terribly knowledgeable or useful. That first level person has access to a knowledgebase that is similar to what you could find by searching online. When that person can't help, they pass you up to a higher level of support that can likely fix your issue.

The other problem with most tech support is timeliness. You are often kept on hold for an extended period of time or are forced to contact support via email or web form and hope that they get back to you within a few hours. It's almost never quick.

My experience with Office 365 support today was amazing. I had a question on Sunday morning at about 11am and had an answer within 10 minutes. Here is what it looked like....
  1. I'm working on some labs and find that in the Exchange admin center, when I attempt to create a distribution group it actually prompts me to create an Office 365 group instead. I confirm this is the case in my own personal Office 365 tenant and a test tenant I'm working with for lab development.
  2. In the Office 365 admin center, in Support, I selected Let us call you. This option is not available until you at least attempt to search for a resolution to your problem.
  3. The Let us call you option showed an estimated wait time of 10 minutes. So, I entered my phone number and waited.
  4. Within about 5 minutes, I got a call from a very helpful person at Office 365 Support (thank you Bel).
  5. She listened to my concern and did a remote view on my system to confirm the issue and identified it as a bug. She offered a work around of creating the distribution list in the Office 365 admin center (which does work) instead of the Exchange admin center.
  6. She also followed up with an email that stated she confirmed the issue in her own test environment and has reported it as a bug in the Exchange admin center user interface. Nice to know that there is a process in place to take care this rather than just giving me the work around.
Here is what was awesome:
  • Support was fast and I knew about how long it would take to be contacted. Sometimes the ambiguity of dealing tech support is the worst part. And, this was Sunday morning, not business hours.
  • The support person wasn't working from a script. She listened to my issue and then wanted to confirm it by remote viewing. There wasn't a long process of "well, let's try this...." I was not treated like a dummy as most tech support does.
  • This level of support is available to anyone. I don't have any special support contract. In fact the tenant for my email that I used to send the support request costs only about $12 per month. That's awesome support for a low cost product.
Update: Since this post, I've learned from Microsoft that the UI change for creating distribution groups in Exchange admin center is not a bug, but a design change. For details, see my other post here: http://byronwright.blogspot.ca/2017/01/o365-unable-to-create-distribution-group.html

Exchange VM Hangs During Updates

I haven't run into this yet, but it appears that in some cases, Hyper-V virtual machines running Exchange Server will hang when installing updates. Specifically this seems to occur when running updates for Hyper-V integration services.

There are reports of KB3037623 specifically causing this issue.
The fix is to:
  1. Disable the Exchange services
  2. Apply the update
  3. Reenable the Exchange services
This blog posting provides detailed steps:

Tuesday, January 10, 2017

PowerShell Learning Resources

I'm doing some onsite PowerShell training this week and realized that I mention lots of resources but haven't provided a list of them anywhere for easy access. So, this posting is my best summary of Windows PowerShell related learning content from Microsoft. There are also a bunch of my links to my blog articles that I use as examples in class.

General Resources

Microsoft makes a lot of content available online for free. Here is a high level list:

Windows PowerShell Resources

Here are some resources specifically related to PowerShell:

PowerShell Examples

The following are examples of using PowerShell from my blog. They may or may not be useful for your purposes. I use them in class as examples that we review.

Wednesday, January 4, 2017

Finding Stale SIDs on GPOs

One of my clients has a tool from Microsoft that scans the AD infrastructure and generates a report of items that can fixed/improved. One of the items on a recent report was stale SIDs on GPOs that could affect GPO processing. However, the tools didn't give us the stales SIDs. Just said we had them.

First, let's talk about what a stale SID is...

All Windows security is based on a Security Identifier (SID) that is unique for each user or group. In the Access Control List (ACL) for an resource, it is the SID that is assigned permissions, not the name of a user or group. The Windows tools just translate that SID back to a user or group name for use to manage them easier.

A stale SID occurs when a user or group has been assigned permissions to access a resource and the user or group is later deleted. There is no link back from the user or group to where the permissions have been assigned. So, Windows cannot go back and remove the SID from the ACL. The SID that's left behind without a matching user or group object is a stale SID. When you are using graphical tools to view permissions and it shows a SID instead of a user or group name, that's typically a stale SID.

NOTE: Just because a graphical tool is showing a SID does not 100% guaranteed that the SID is stale. It could be a user or group from a trusted domain that the tool is having trouble resolving. If you have trusted forests or domains, you should verify that SID is in your domain.

If there were only a few GPOs, it would be fairly fast to use the Group Policy Management Console to find the stale SIDs. However, this client had about 500 GPOs and manually verifying the permissions would have been quite painful.

To find the stale SIDs on GPOs, I wrote up a small script that scans the GPOs and finds any security permissions that are unknown:

 Import-Module GroupPolicy  
 $gpo = Get-GPO -All  
 Foreach ($g in $gpo) {  
   $permissions = $g.getsecurityinfo()  
   Foreach ($p in $permissions) {  
     If ($p.Trustee.SidType -eq "unknown") {  
       Write-Host "Policy with unknown SID: $($g.DisplayName)"  
       Write-Host "Trustee SID: $($p.Trustee.Sid)"  
     } #end if  
   } #end foreach permissions  
 } #end foreach gpo  

Here is what the script does:
  • Loads the GroupPolicy module (required for Windows Server 2008 R2, Windows Server 2012 will do that automatically.
  • Pulls all GPOs into the variable $gpo.
  • Starts a foreach loop to process each gpo in $gpo.
  • Pulls the permissions for the current GPO into the $permissions variable by suing the getsecurityinfo() function for gpo objects.
  • Starts a foreach loop to process each permission in $permissions.
  • Tests whether the SidType for the trustee in the permissions is unknown. An unknown SidType identifies a SID that couldn't be resolved to a user or group.
  • The name of the gpo and the SID of the trustee are written to screen.
 This script writes output to screen, but you could easily modify it to dump the output to fine instead.

Thursday, December 29, 2016

Windows Server 101 (Free eBook)

I just saw that a colleague Brian Svidergol (@bsvidergol) has released a free ebook, named Windows Server 101, about the basics of Windows Server. I've worked with Brian on several projects and he knows his stuff.

If you are new to working with Windows Server or want to brush up on the basics, I suggest you check it out:

Wednesday, December 21, 2016

Certificate Template Versions and Autoenrollment

Certificate templates for Active Directory Certificate Services (AD CS) have multiple values related to versioning. In the Certificate Templates console, you can see two versioning attributes:
  • Schema Version - This defines the options available in a Certificate Template. If you search for information about certificate template versions (such as https://technet.microsoft.com/en-us/library/cc725838(v=ws.11).aspx), the reference to different versions is the schema version. These schema versions are consisten across Windows servers.
  • Version - This number is unique for your AD CS implementation. When you modify the template, this version number is incremented.
Byron Web Server template: Schema Version 2, Version 100.3

The version number for your certificate templates is composed of a major version number and a minor version number. In this example:
  • Major version: 100
  • Minor version: 3

When you make any edit to a certificate template, the minor version number is incremented. Even minor edits such as changing the security configuration for the certificate template increment the minor version number. This number is primarily for your own auditing purposes to identify that a change has been made. Incrementing the minor version number has no immediate impact on clients using autoenrollment.

When you right-click a certificate template and select Reenroll All Certificate Holders, the major version number is incremented and minor version number is reset to zero. Clients using autoenrollment see that major version has been incremented and renew their certificate using the updated certificate template.

If you use ADSIedit to view the properties of a certificate template, you can see the major and minor version numbers stored as the following attributes:
  • revision
  • msPKI-Template-Minor-Revision

If you manually edit the revision attribute and increment the value, it will trigger an update for autoenrollment clients just as if you had selected the Reenroll All Certificate Holders option in the Certificate Templates Console.

On the client side, autoenrollment is triggered by a scheduled tasks in \Task Scheduler Library\Microsoft\Windows\CertificateServiceClient. The triggers for enrollement are:
  • SystemTask (for computer certificates): At startup, repeat every 8 hours
  • UserTask (for user certificates): At sign in, repeat every 8 hours

If you are testing, you can manually run these tasks rather than restarting the computer or signing out and signing back in.