Microsoft Sender ID Framework SPF Record Wizard

There is a lot of different great posts out there that describes SPF and how to create the records. But not so many posts that refers to the Sender ID Framework SPF Record Wizard provided by Microsoft.

Have a look at the wizard if you are planning to implement SPF, it provides the option to easily generate all SPF records you need. It can be found here!

One-liner to export all email addresses to CSV

This command exports all email addresses for all users in the organization:

Get-Mailbox -ResultSize Unlimited | Select-Object DisplayName, SamAccountName, PrimarySmtpAddress, @{Name="EmailAddresses";Expression={$_.EmailAddresses | Where-Object {$_.PrefixString -ceq "smtp"} | ForEach-Object {$_.SmtpAddress}}} | Export-CSV c:\EmailAddresses.csv -NoTypeInformation -Encoding Unicode

If you want to narrow it down a bit you could add either a Where or narrow the scope sown to a specific OU as in the following example:

Get-Mailbox -ResultSize Unlimited -OrganizationalUnit "sundis.local/Test/Users" | Select-Object DisplayName, SamAccountName, PrimarySmtpAddress, @{Name="EmailAddresses";Expression={$_.EmailAddresses | Where-Object {$_.PrefixString -ceq "smtp"} | ForEach-Object {$_.SmtpAddress}}} | Export-CSV c:\EmailAddresses.csv -NoTypeInformation -Encoding Unicode

Let me know if you have any questions!

Users is unable to access OWA options (ECP) in Exchange 2010 and 2013

This is not an especially new issue but there is not much information about it so here goes anyway.

The issue

Some users, but not all, of a customer of mine reported that they could not save their signatures in OWA. After some investigation I found that the users that could save their signature had the an Role Assignment Policy set, “Default Role Assignment Policy”. This was the only policy in use and all users should have that policy.

When I did a quick check online, some had reported that the following event with event ID 4 and the error message "The user "username" isn’t assigned to any management roles."  where logged in the Application Log on the CAS servers. However, my customer had no such events in the Application Logs on their CAS servers.

The users that could not save their signature had an empty Role Assignment Policy attribute set. Exchange needs to have the RoleAssignmentPolicy property (msExchRBACPolicyLink  attribute) to be able to determine which settings the users has the rights to change in ECP. This is based on RBAC and if you want to read up on Role Assignment Policies have a look here.

Lets have a look at this in more detail. I have got two users, Test User1 with no policy set. And Test User2 with the “Default Role Assignment Policy” set. We will start with the first user…

 

A broken Mailbox

Test User1 (no policy set)
Run the following command to view the RoleAssignmentPolicy property.

Get-Mailbox <identity> | Name,RoleAssignmentPolicy

Example:

As you can see, the RoleAssignmentPolicy property is empty. In ADSI Edit the attribute you should look for is called msExchRBACPolicyLink as shown below.

As you probably have guessed already, the attribute is empty for Test User1. If I go to OWA and try to change some of the options I receive the following error message “Sorry! Access Denied. You don’t have permission to open this page. If you’re a new user or were recently assigned credentials, please wait 15 minutes and try again.”.

In both Exchange 2010 and 2013 the message looks like this.

 

A working mailbox

Test User2 (“Default Role Assignment Policy” set)

Again, run the following command to view the RoleAssignmentPolicy property:

Get-Mailbox <identity> | Name,RoleAssignmentPolicy

Example:

Much better as you can se, when we use ADSI Edit the msExchRBACPolicyLink contains the Distinguished Name of the “Default Role Assignment Policy”.

For Test User2 it works fine to change the settings in ECP.

 

Why did it happen?

I did some more investigating and found that the reason that this issue occurred for some users was that my customer create some mailboxes using AD Toolkit. When AD Toolkit creates the mailboxes the msExchRBACPolicyLink attribute is not set.

This can be achieved in AD Toolkit as well by adding an attribute when creating the mailboxes and specifying the msExchRBACPolicyLink attribute with a correct Role Assignment Policy.

 

Solution

Well the easiest way to solve the issues is to add a Role Assignment Policy for the affected mailboxes. To find all users with an empty msExchRBACPolicyLink attribute you can run the following command.

Get-Mailbox -ResultSize Unlimited | Where { $_.RoleAssignmentPolicy -like $null}

Example:

To add a Role Assignment Policy for all the listed users run the following command:

Get-Mailbox -ResultSize Unlimited | Where { $_.RoleAssignmentPolicy -like $null} | Set-Mailbox –RoleAssignmentPolicy “Default Role Assignment Policy”

Example:

And that should be it, all users should now be able to change their settings in ECP.

Thanks for reading and do not hesitate to let me me know if you run in to any issues!

MEC returns in April 2014!

Great news from Microsoft today, Microsoft Exchange Conference will return in April 2014. Keep an eye on www.mecisback.com and #IamMEC, no news on the site yet but save the date!

iOS 6.1.2 released with fix for Exchange calendar synchronization bug

When iOS 6.1.1 was released in January it contained a bug that caused excessive IIS logging on Exchange CAS servers. The bug was related to the synchronization of calendar events. A while ago Apple announced that iOS 6.1.2 would include a fix for the issue.

The workaround where to either block devices that ran iOS 6.1.1 or handle the devices using a throttling policy. But today Apple gave us some good news, the release of iOS 6.1.2.

Apple KB can be found here.

Microsoft KB can be found here.

Multiple updates released including SP3 for Exchange 2010

Service Pack 3 for Exchange 2010

Microsoft has released a number of updates. The big news here is the release of Service Pack 3 for Exchange 2010 with the two following major features:

Coexistence with Exchange 2013
Support for Windows Server 2012

Great new for all of you wanting to implement Exchange 2013 in your existing environments. But coexistence also requires an update of Exchange 2013.  CU1 for Exchange 2013 is scheduled for release in Q1 so it should be released soon. That said, installing Exchange 2013 in a existing Exchange 2010 Service Pack 3 environment WILL work all tough it is not supported. But it enables you to start running tests in your lab and prepare for the release of CU1.

More information on SP3 for Exchange 2010 can be found here.
If you want to go straight to the download you can find it here.

More updates…

But wait, there is more… Microsoft has also released Update Rollup 6 for Exchange Server 2010 SP2 and Update Rollup 10 for Exchange 2007 SP3. Both are considered security releases so they will be available on Windows Update.

More information on these can be found here.
Update Rollup 6 for Exchange Server 2010 SP2 can be found here.
Update Rollup 10 for Exchange 2007 SP3 can be found here.

Bulk copy SAMAccountName to Alias using PowerShell

Just a short one to show how to copy the SAMAccountName to Alias using PowerShell. You can easily change the initial population of $Mailboxes and test the script on a single, or smaller number of users.

You also need to remove the Write-Host commands and -ErrorAction Inquire –Whatif in the Set-Mailbox command after your testing.

During testing:

$Mailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox

foreach ($Mailbox in $Mailboxes)

{
	$SAMAccountName = $Mailbox.SAMAccountName
	$OldAlias = $Mailbox.Alias

	if ($SAMAccountName -ne $OldAlias)
	{
		Write-Host $Mailbox.SAMAccountName
		Write-Host $Mailbox.Alias
		
		Set-Mailbox $Mailbox -Alias “$SAMAccountName” -Confirm:$false -ErrorAction Inquire -Whatif
		
		Write-Host
	}
}

After testing:

$Mailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox

foreach ($Mailbox in $Mailboxes)

{
	$SAMAccountName = $Mailbox.SAMAccountName
	$OldAlias = $Mailbox.Alias

	if ($SAMAccountName -ne $OldAlias)
	{
		Set-Mailbox $Mailbox -Alias “$SAMAccountName” -Confirm:$false
	}
}

Verifying the changes:

Listing all mailboxes where SAMAccountName and Alias differs…

Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox | Where {$_.SAMAccountName -ne $_.Alias}

Let me know if you have any questions, thanks for reading!

List empty distribution groups

A short tip on how to list all empty distribution groups. In this example I export the results to a csv file.

$DistributionGroups = Get-DistributionGroup -Resultsize Unlimited
$DistributionGroups |? {!(Get-DistributionGroupMember $_)} | Select-Object Name | Export-Csv "C:\EmptyDistributionGroups.csv"

Enable users to manage distribution groups without new- or remove- Cmdlets using Management roles

In this post I will show you how to create a management role and assign it to a group. We will remove the new- and remove Cmdlets from the Management role and make sure that it works. This will enable the users to manage distribution groups without the permission to create or remove any distribution groups.

You might want to give the users permission to manage the groups they are managers of without the possibility to create new groups or remove current groups. This will give you a more controlled distribution group management without new groups popping up. One customer of mine use a distribution group administrator for each department that is instructed and responsible for creation and removal of groups concerning that users department.

The Management role

The first thing we need to do is to create a new Management Role. We do this since we do not want to edit a built-in management role. What we can do, is base our new Management Role on one of the built-in Roles, by doing that we will populate our new Role with the same Management Roles Entries.

To create a new Management Role and use the following cmdlet:
New-ManagementRole -Name "MyDistributionGroupsAdmins" -Parent MyDistributionGroups

Next we will remove the new- and remove-.cmdlets from our new Management Role. But first we will check the cmdlets:
Get-ManagementRoleEntry "MyDistributionGroupsAdmins\New-*"

When we a re sure that these cmdlets are the once we want to remove run the following cmdlet:
Get-ManagementRoleEntry "MyDistributionGroupsAdmins\New-*" | Remove-ManagementRoleEntry

We will do the same for the Remove- cmdlets:
Get-ManagementRoleEntry "MyDistributionGroupsAdmins\Remove-DistributionGroup

We only want to remove one of the cmdlets:
Get-ManagementRoleEntry "MyDistributionGroupsAdmins\Remove-DistributionGroup” | Remove-ManagementRoleEntry

Now we have a new Management Role without the New- and Remove- cmdlets. Next we want to assign the Role to our users is some way. I will explain three different ways of doing this.

Assignment using Management Role Group

When we use this method we will create a Role Group, add members and managers to the group and add our previously created Management Role to the Group. A Management Role Group also includes a Universal Security Group that s created during the process.

I am not going to go through exactly how Management Role Groups work , more information on this can be found here.

When creating the Role Group use the following command:
New-RoleGroup -Name "Distribution Group Managers" -Roles "MyDistributionGroupsAdmins" -Members Test10, Test11,Test12 -ManagedBy Test12

This creates a new Role Group, adds the users Test10 and Test11 as members and the user Test12 as manager. Test12 will get both the rights that the Role Group incudes and he will have the permission to manage the group.

To be able to confirm that our configuration works we need to create a Distribution Group and set user Test12 as owner, I use the following command to achieve this:
New-DistributionGroup -Name "Test Group 1000" -OrganizationalUnit "sundis.local/Test/users" -SAMAccountName "TestGroup1000" -Type "Distribution" -ManagedBy Test12

Now we can log on to the ECP as our manager, Test12 in my case, and see if our configuration work. Open ECP, log in and navigate to Groups. Select the group you want to manage in the right column Public Groups I Own and click Details or double click it.

Add a user by expanding Membership and click Add.

Select the mailboxes you want to add to the group, click Add and Ok.

Check that your changes looks ok and then click Save.

You should now be back at ECP and our test is finished and successful.

Assignment using a new Management Role Assignment Policy

The second option I am going to explain is the use of a Management Role Assignment Policy. Using a policy enable you to group a number of Management Roles together to a policy and configure mailboxes to use this policy. Again, I will not do any deep dive in Management Role Assignment Policies, more information on this can be found here.

We will use the same Management Role as we created above and start with creating a new Policy. Note that we also include a role called MyBaseOptions. If we leave this role out it will prevent users who are assigned this policy from using ECP and OWA options. Use the cmdlet below to create the policy:
New-RoleAssignmentPolicy "Distribution Group Admins" -Roles MyBaseOptions, MyDistributionGroupsAdmins

If you want to make this Policy default add –IsDefault as in the following example:
New-RoleAssignmentPolicy "Distribution Group Admins" -Roles MyBaseOptions, MyDistributionGroupsAdmins –IsDefault

When the Policy is created you can add it to a mailbox with the following cmdlet:
Set-Mailbox Test10 -RoleAssignmentPolicy "Distribution Group Admins"

And  a simple Get-Mailbox to check the results:
Get-Mailbox Test10 | fl Role*

Again, lets check this using the ECP for mailbox Test10. For this test I create a new Distribution Group called Test Group 1001 and add Test 10 as manager using the following cmdlet:
New-DistributionGroup -Name "Test Group 1001" -OrganizationalUnit "sundis.local/Test/users" -SAMAccountName "TestGroup1001" -Type "Distribution" -ManagedBy Test10

In ECP, navigate to Groups. Select the group you want to manage in the right column Public Groups I Own and click Details or double click it.

Add a user by expanding Membership and click Add.

Select the mailboxes you want to add to the group, click Add and Ok.

Review the changes you have made and click Save when finished.

This will take you back to ECP and we are finished with this part.

Assignment by customizing the Default Management Role Assignment Policy

Last but not least we will add our Role to  the Default Management Role Assignment Policy. To achieve this we create a new Management Role Assignment by running this cmdlet:
New-ManagementRoleAssignment -Name "Default Role Assignment Policy – MyDistributionGroupsAdmins" -Role MyDistributionGroupsAdmins -Policy "Default Role Assignment Policy"

Now all the mailboxes with the Default Role Assignment Policy configured will have the ability to manage the distribution Groups they are managers for. Since I like screenshots I will make sure this is ok. First create a new Distribution Group:
New-DistributionGroup -Name "Test Group 1002" -OrganizationalUnit "sundis.local/Test/users" -SAMAccountName "TestGroup1002" -Type "Distribution" -ManagedBy Test11

Let’s also make sure that the mailbox Test11 have the Default Role Assignment Policy set:
Get-Mailbox Test11 | fl Role*

Now we can log in to ECP and make sure that we can manage Test Group 1002. Select the group you want to manage in the right column Public Groups I Own and click Details or double click it.

Add a user by expanding Membership and click Add.

Select the mailboxes you want to add to the group, click Add and Ok.

Review the changes you have made and click Save when finished.

All done, the Default Policy is altered and tested.

I hope you like the post and find it useful. Thanks for reading and let me know if you have any questions!

Quick Tip: View the database size and mailbox count for mailbox databases

In this quick tip post I will show you how to retrieve mailbox database size and mailbox count for one or all mailboxes. Lets start with mailbox database size.

Mailbox database size

This command is quite simple and utilizes the –Status parameter in the Get-MailboxDatabase cmdlet:

Get-MailboxDatabase –Identity <MailboxDatabaseName> -Status | Select ServerName,Name,DatabaseSize

To retrieve the size of all mailbox databases:

Get-MailboxDatabase -Status | Select ServerName,Name,DatabaseSize

And if you want to sort this on DatabaseSize:

Get-MailboxDatabase -Status | Select ServerName,Name,DatabaseSize | Sort-Object DatabaseSize –Descending

And with sorting on the mailbox database name:

Get-MailboxDatabase -Status | Select ServerName,Name,DatabaseSize | Sort-Object Name –Descending

Mailbox count for mailbox databases

Now we will focus on counting mailbox databases. This command is also quite easy to use.

Get-Mailbox -ResultSize:Unlimited | Group-Object -Property:Database | Select-Object Name,Count | Sort-Object -Property:Count –Descending

Let’s break this up a bit… The first part is a ordinary Get-Mailbox cmdlet with -ResultSize:Unlimited to include all mailboxes:

Get-Mailbox -ResultSize:Unlimited

Then we group the objects from the result of the Get-Mailbox cmdlet on Database to be able to count based on each mailbox database:

Group-Object -Property:Database

Moving on with a selection of the properties we want to display including a count:

Select-Object Name,Count

And finally we sort the results based on the count property to get it in a nice list with the mailbox database with most mailboxes on top:

Sort-Object -Property:Count -Descending