Matt's Blog

New Layout options for Outlook Web App in Exchange 2013 and Office 365 (Post-Upgrade)

Matthew Abraham — Thu, 09 May 2013 15:07:35 GMT

There are some really cool and lesser known options for OWA in the new wave of Exchange and Office 365. The default view is great, but can be a little over the top for a smaller device. And for those who cant use Activesync, you may want a better way to get mail on your Surface/Windows Phone (or Ipad/Iphone)

By default, OWA looks like this:

Which is great for a desktop, but not on a smaller screen. You can modify the Outlook Web App view with a couple of easy switches, which can be saved in your favourites

The first, is designed for your tablet. Just add ?layout=twide to your OWA URL (eg. https://mail.contoso.com/owa/?layout=twide) It will now look like this

Much easier to see on a small screen, and much more finger friendly. Especially when viewed through Modern IE on a Surface/Touch device!.

But what if you are on a phone. Try adding ?layout=tnarrow and you will get the view below (beautifully demonstrated through the WP8 emulator)

Perfect for a mobile OWA wouldn’t you say?

And finally, to complete my list, you can use ?layout=light to get to OWA light, and ?layout=normal to return to the normal OWA view. All of these options will work for both Exchange 2013 and the new Office 365.

Hopefully you find this useful. Please let me know in the comments below!

How to connect Office 365 (Post Upgrade) to a POP or IMAP Account

Matthew Abraham — Thu, 09 May 2013 09:41:00 GMT

Today I was working on a customer issue where they were unable to connect Thunderbird to an Office 365 account. Normally I would say “Use Outlook”, and in most cases Outlook provides the best experience. But… I was also curious as to why this wasnt working. Turns out, the way things try to auto configure in Thunderbird doesn't quite match what we need in O365. So.. here is a step by step.

1. Begin to create a new profile in Thunderbird, and enter your name, and Office 365 Email Address and Password. Hit Continue.

Thunderbird will fail to find the settings

Configure the settings as follows:

Incoming (POP3) : Server Hostname: Outlook.office365.com. Port 995. SSL: SSL/TLS Authentication: Normal Password

Incoming (IMAP): Server Hostname: Outlook.office365.com. Port 993. SSL: SSL/TLS Authentication: Normal Password

Outgoing (SMTP): Server Hostname: SMTP.office365.com. Port:587 SSL: STARTTLS Authentication:Normal Password

Username: *Your Full Office 365 Login Name"*

You should see this:

Click the “Done” button. Do not click “Re-Test”

Thunderbird will validate the configuration and….

Success!. Then try to send a mail, and if it sends correctly, you have configured Thunderbird to connect to Office 365. If you can receive but cannot send, verify the SMTP configuration matches above (specifically the STARTTLS SSL)

How to enable ActiveSync Logging in Office 365 and On Premise

Matthew Abraham — Wed, 08 May 2013 15:06:52 GMT

There are times when you have an ActiveSync device that isn’t behaving properly. Maybe mail is getting stuck in the outbox, maybe the calendar isn’t looking right. There are a number of issues that could cause this, but in an Office 365 environment, you might think you are limited as to the logging that you can collect

Not So!

You can enable advanced logging on a Per User/Per Device basis from within OWA, and then analyse the output. Simply browse to OWA, Go options (Into ECP) and then choose phone. Be aware that this will only work once the device has connected to Exchange at least once.

Click the following button to enable logging:

Then click the same button to retrieve the log. The user will receive an email with an attachment, which should show all ActiveSync activity during the trace. Hopefully, if there was an issue, it will show up in the log.

Hopefully, I will have a followup post with what to look for coming up aswell!

Cross Premise Calendar Sharing with Office 365

Matthew Abraham — Tue, 07 May 2013 12:39:00 GMT

There are two ways to share read access to your calendar across premise (On Premise to Office 365 or Office 365 to On Premise) The method you choose will depend on your requirements, and the level of access that you would like to give to the calendars.

Neither of these methods will provide write access to the calendar, which is not possible in a Cross-Premise scenario. We recommend that any teams who share a calendar, or shared mailboxes that have a calendar in them, are moved to the cloud at the same time, so everyone is able to continue to use the calendars without interruption.

Default Sharing (Organizational Relationship)

The preferred way to share a calendar Cross Premise will be to use the Default Sharing. This uses the Organizational Relationship which has been set up, to provide access up to the “Limited Details” level (Subject/Location/Organizer & Free Busy). The main limitation to this is that it is an “all or nothing” for the user, and anyone in the organization will be able to see the calendar.

From an Administrator perspective, The Organizational relationship should have been set during the initial configuration by the Hybrid Wizard. To verify this, run the Get-OrganizationRelationship powershell cmdlet, and ensure that the hybrid is set up with the access level of “LimitedDetails” You will need to do this on both the Cloud Organization and On-Premise.

Then, users will need to follow the instructions below:

Right click on your calendar, and choose “Properties”

You can then choose the level of access for the “Default” entry.

Please be aware that the maximum level of cross premise access will be Free/Busy time, Subject and Location. If you set the setting higher, users in the same Exchange environment will have the higher rights, but users in the other environment will be limited to this setting.

This will allow someone to see your meetings within Outlook, but not open an individual meeting to see the body within.

The following table shows the effective permission, based on Admin configuration and User settings:

Federated Calendar Sharing

If it is a requirement to open a meeting and see the details, or control permissions on a more granular basis, then the remaining option is to use federated calendar sharing. This involves sending an invitation to users who need full access, and they will open the calendar from Outlook.

The administrator must first create a sharing policy for both the On-Premise Organization, and the Cloud Organization, and specify the domains that a user will be allowed to share with. This will need to be all internal domains, so if the corporate domain is “Contoso.com” both policies will need an entry of “Contoso.com” with the appropriate permission. Once again, the Admin has the option to set a number of different permissions.

To send the invitation, Right click on the calendar, go to share, and then share Calendar

The User will then need to grant the appropriate level of access.

Fill in the sharing invite, and send this to the users who need to review the calendar.

When the receiving user opens it, it can take up to 15 minutes to populate on the recipients view, but they will then have the permission specified. This will also enable a user to give a default Free/Busy view, but give others a higher level of permissions if required. The table below shows the effective permissions. Where the table is black, the user will be prevented from sending the sharing invite.

Hope you find this useful . Let me know of any questions in the comments below.

How to prevent your Exchange Database Drives filling up completely. Or Disk Space monitoring on a budget

Matthew Abraham — Thu, 07 Feb 2013 14:03:00 GMT

We have all been there. We create our brand new Exchange system, size the server correctly using the Mailbox Calculator, and create our Disks based on the estimated maximum sizes. We give the database to our users, and without adequate monitoring, it grows and grows and grows. Despite what we all think, not every company has SCOM 2012 with all the monitoring goodness that provides (other monitoring solutions are available)

This is a quick and simple way to prevent running out of disk space on a database drive, which can cause large amounts of downtime. Lets take a recent customer as an example

They have a 200GB lun configured to host a database (DB1) and the associated log files. After running through the mailbox storage calculator, and ensuring that they have enough space for the content index,Logs and contingency, they settled on a max database size of 110 GB.

First thing to do, is find the Mailbox Guid associated with our database. We can do this with the command Get-MailboxDatabase | FL Name,Guid

Record the relevant GUID somewhere safe.

Open up Regedit, and Browse to HKLM\System\CurrentControlSet\Services\MsExchangeIS\*ServerName*\Private-*Guid*

Add a New DWORD Value called “Database Size Limit in GB” (it is case sensitive) and add the size limit in decimal. From the screenshot above, we have set a 110GB limit. Now Restart the Information store.

Within a DAG, the Guid will be the same for each database, but you must set this on each member of the DAG.

This will ensure that when the database reaches a certain size, it will be dismounted. Note this is not an immediate dismount, but it will occur at around 8am in the morning (By default) . Therefore, this wont protect you in the event of a sudden spike in database size.

Now, just having your database dismount isn't the best way to alert you of an issue. Therefore, when the database hits 90% of the configured size (appox 99GB in this case) then an event will be logged in the Application Log. Specifically, MSExchangeIS EventID 9688. With the wonders of Server 2008 Task Scheduler, you can configure an email alert when an event is logged.

Open Task scheduler, and Create a new Basic Task.

Configure the task to begin on an event, and configure the trigger as shown below:

Then, under the actions, configure the action of “Send an Email”, and under SMTP server, configure the address of a hub transport server. If the hub role is installed on the local server, you can use 127.0.0.1

Configure your alerts with the correct message text, and create the task. Finally, go into the security options, and set it to run whether a user is logged in or not. Also it would be prudent to create a service account to run this task as, or run it as local system.

This should prevent the awkward situation of a database completely filling the disk, and having to quickly find more storage. By alerting you, and setting the size limit low enough, even if you need to provision new disk, you should be notified early enough to take corrective action! When the alert comes, if you have the space available, you can change the registry key to increase the size, and ensure that your users can keep working whilst you source some new storage.

How to patch the Multi Role DAG

Matthew Abraham — Wed, 28 Nov 2012 16:05:41 GMT

I recently had a conversation with one of my customers who is about to patch their multi-role DAG environment. I thought this would make a great blog post, with the step-by-step information.

The customer environment looks like this:

Site 1 is the primary site, and mailbox databases are distributed evenly between SERVER1 and SERVER2. The Sites are a single Active Directory site, spread over 2 physical sites.

The load balancer has been configured to send client traffic to all three servers for Client Access.

So, we need to patch this system. One of the key things when patching Exchange, is to remember that you always need a newer server, talking to an older server. In this case, a newer CAS, talking to an older mailbox. This creates some “Interesting” Load Balancer gymnastics.

We will start by patching Server 1.

To start with, Drain stop the connections on the Load Balancer from server one. Your client connections will now be going to Server 2 and Server 3.

Once all connections to Server 1 have ended, use the Start-DAGServerMaintenance Script on Server 1. This will pause the node in the cluster, move all active databases to another node, and set the DatabaseCopyAutoActivationPolicy to blocked. All Mailbox Database Copies will be suspended, and if the node owns the cluster core resources, these will be moved to another node.

At this point, we are able to patch Server 1. Run the required Service Pack or Update Rollup on this server.

Now we can run the Stop-DagServerMaintenace Script on Server 1. This will return the server to service, but will NOT automatically remount the databases. This is good, as we don’t want our “older” CAS servers to connect to our “Newer” mailbox servers.

Next, reconfigure the load balancer to connect clients to Server 1, and Drain stop Servers 2 and 3.

When all client connections are going through Server 1, Move all Databases to Server 1, and Start DAG Maintenance on Servers 2 and 3.

Patch Servers 2 and 3

Stop DAG Server maintenance on Servers 2 and 3, and Re-Add them to the Load Balanced Pool

Run the DistributeActiveDatabases.ps1 script to re-distribute your databases based on your Activation Preference.

This is a simple process to patch the Multi Role DAG. Please let me know if you have any questions or comments!

Block Mobile apps that use Exchange Web Services

Matthew Abraham — Thu, 23 Aug 2012 10:51:52 GMT

We all know that with Exchange 2007 and Exchange 2010, ActiveSync is the preferred option for Mobile Devices to connect and synchronize mail. However, some business do not wish ActiveSync devices to connect, preferring to opt for a solution such as BES or Good sync. These businesses will often disable ActiveSync at the user account level, and then allow access to a small number of users who are permitted to use their non-corporate standard mobile device.

However, Some mobile apps use an alternative way to collect their email from the Exchange Environment. They will use Exchange Web Services to pull the email from Exchange, bypassing the security policies and control afforded by ActiveSync.

Disabling EWS isn’t really an option, as quite a lot of Outlook functionality relies on EWS. However, we have a few lesser-known pieces of functionality to block EWS for certain applications, based on their User Agent Strings.

We can control the usage of EWS by using the Set-CASMailbox cmdlet for a single user, or the Set-OrganizationConfig cmdlet to set the settings for the organization.

The Parameters to use with both of these cmdlets are below:

EwsAllowEntourage	The EwsAllowEntourage parameter specifies whether to enable or disable Entourage 2008 to access Exchange Web Services (EWS) for the entire organization. The default value is $true.
EwsAllowList	The EwsAllowList parameter specifies the applications (user agent strings) that can access EWS when the EwsApplicationAccessPolicy parameter is set to EnforceAllowList.
EwsAllowMacOutlook	The EwsAllowMacOutlook parameter specifies whether to enable or disable Microsoft Outlook for Mac 2011 to access EWS for the entire organization.
EwsAllowOutlook	The EwsAllowOutlook parameter enables or disables Microsoft Office Outlook 2007 to access EWS for the entire organization. Outlook 2007 uses EWS for free and busy information, out of office settings, and calendar sharing.
EwsApplicationAccessPolicy	The EwsApplicationAccessPolicy parameter defines which applications other than Entourage, Mac Outlook, and Outlook can access EWS. If set to EnforceAllowList, only applications specified in the EwsAllowList parameter are allowed access to EWS. If set to EnforceBlockList, every application is allowed access to EWS except the ones specified in the EwsBlockList parameter.
EwsBlockList	The EwsBlockList parameter specifies the applications that can't access EWS when the EwsApplicationAccessPolicy parameter is set to EnforceBlockList.
EwsEnabled	The EwsEnabled parameter specifies whether to globally enable or disable EWS access for the entire organization, regardless of what application is making the request.When the EwsEnabled parameter is set to $false, EWS access is turned off, regardless of the values of the EwsAllowEntourage, EwsAllowMacOutlook, and EwsAllowOutlook parameters. For the EwsAllowEntourage, EwsAllowMacOutlook, EwsAllowOutlook parameters to be meaningful, the EwsEnabled parameter must be set to $true.

By using these parameters, we can either Allow or Block EWS by default, and turn on/off certain applications. In the case of blocking specific applications from using EWS, we would allow EWS by default, and block these offending apps. Of course, the opposite can be completed as well, Block EWS by default, and allow required apps.

The Block/Allow lists work on the basis of the User Agent Strings generated by the EWS client. So, if you are looking to get a list of strings to block, you can take a look at your IIS logs.

A Log Parser command such as the following can be used:

logparser.exe “SELECT date,time,c-ip,cs-username,cs-uri-stem,cs(User-Agent) INTO C:\Temp\EWSLog FROM “\\EXCHSERVER01\c$\inetpub\logs\logfiles\W3SVC1\u_ex1207*.log” WHERE cs-uri-stem LIKE ‘/EWS/Exchange.asmx’ AND cs-username IS NOT NULL” –I:IISW3C –o:TSV –headers:Auto –filemode:1

Explanation of the LogParser command:

WHERE cs-uri-stem LIKE ‘/EWS/Exchange.asmx’ – Ensures we are dealing with the EWS access parts of the IIS logs.

AND cs-username IS NOT NULL – Ensures we get userIDs back

-o:TSV – outputs to a tab-delimited file

-filemode:1 – overwrites the output file if it exists

If subsequent date from other Exchange Servers is required to be amended to the output file, set filemode to ‘0’

You can then load the resulting TSV into Excel, and create a pivot table showing the User Agents that are accessing EWS.

Interestingly in here, we can see that the BES is using EWS, and a lot of OWA/*Darwin style entries. From research, these appear to be Iphone apps syncing with EWS rather than ActiveSync.

So.. How can we block these?

Well , We can use the EWSBlocklist parameters. And the best bit, The parameters accept WildCard entries

We can set these at both the individual mailbox level, and at the organization level. It is strongly recommended to do a test with a test user first, and then ensure everything is working before rolling out on an organization wide basis.

By default, the EWS config settings will look like this

To block for instance all the OWA/* apps, you can run the following commands

Set-CASMailbox –identity “TestMailbox" –EWSApplicationAccessPolicy:EnforceBlockList –EWSBlockList:”OWA/*”
–EWSAllowOutlook:$True –EWSAllowMacOutlook:$true –EWSAllowEntourage:$true –EWSEnabled:$true

At this point, I would recommend running a full suite of tests against this test mailbox. Outlook 2010 access (focusing on Mailtips, OOF and freebusy, which all use EWS) Outlook for Mac (everything uses EWS) Blackberry (calendaring can use EWS).

Then try to connect the offending applications, and see if they are successfully blocked.

If this passes the testing, you can then look to run a wider test, and then when complete, run the Set-OrganizationConfig command to set this for the whole org.

Set-OrganizationConfig –identity “TestMailbox" –EWSApplicationAccessPolicy:EnforceBlockList –EWSBlockList:”OWA/*”
–EWSAllowOutlook:$True –EWSAllowMacOutlook:$true –EWSAllowEntourage:$true –EWSEnabled:$true

When complete, check the following settings with Get-OrganizationConfig

I would strongly recommend a communication to your user community before blocking this, as some users may have a relevant business reason to connect their ActiveSync device to the org. Also, remember that by using ActiveSync rather than EWS, users will be subject to the security policies set, and functionality such as Remote Wipe becomes available.

If you have found this useful, or if you have any questions, please let me know in the comments below!

Many thanks to Ed Crossley for his assistance with the images and some of the great content in this post.

Ed runs his own blog too, which you can find at http://exchangehero.tumblr.com/

Manage Groups with Groups in Exchange 2010

Matthew Abraham — Tue, 03 Apr 2012 14:19:00 GMT

Its been a while since I have posted anything useful, so I might as well start again!

A Common issue with Exchange 2010 is that you are unable to allow a Distribution list to be managed by a “group”. This was changed by design in Exchange 2010 to allow greater separation of Active Directory and Exchange management using Split Permissions, a feature that a number of our customers asked for. A great workaround was created, which enumerates a group, and adds each member into the “Managed By” list in Exchange.

http://blogs.technet.com/b/exchange/archive/2011/05/04/how-to-manage-groups-with-groups-in-exchange-2010.aspx

This works brilliantly, but has one or two limitations. The main limitation is that after a Security Group’s membership is updated, either an Administrator has to run the Mode3 switch of the script, or a period of time has to pass until the script runs in Mode3 as a scheduled task.

For some users, this isn’t fast enough. There is however another way to achieve this.

You can use RBAC to create a security group that is allowed to manage permissions on a distribution group. By doing this, the membership is updated immediately, and any member of the security group will be able to manage the distribution group without waiting for the “managed by” attribute to be updated. There are a few limitations to this as well, which I will describe in a moment.

Lets start by thinking what happens when a user tries to manage a Distribution List.

When Outlook attempts to make changes, these changes are sent to a CAS 2010 server (via the Address Book Service). The Address Book service will then run the corresponding PowerShell cmdlet (such as Add-DistributionGroupMember) based on the RBAC rights of the user making the change. If the user doesn’t have the correct RBAC rights, the command fails, and the error above is given.

So, an alternative method, is to ensure that the user does have the correct rights.

The first step, is to create a customised version of the MyDistributionGroups management role, with which we can scope with a management scope. To do this, we can take the “Distribution Groups” role group, and remove any unneeded commands.

This allows the MyDistManagers role to closely mirror the the MyDistributionGroups role. If we left these commands in place then the users would have greater permissions than we intended. Whilst this will not affect their abilities in Outlook, if they were to run Powershell, and connect to the Exchange environment, they may be able to do a lot more than we intended (such as deleting the distribution group).

get-managementrole "Distribution Groups" | New-ManagementRole "MyDistManagers"

get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Disable-distributionGroup"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "enable-distributionGroup"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-ADServerSettings"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-AcceptedDomain"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-DomainController"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-DynamicDistributionGroup"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-MailUser"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-Mailbox"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-OrganizationalUnit"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-ResourceConfig"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Get-User"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "New-DistributionGroup"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "New-DynamicDistributionGroup"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Remove-DistributionGroup"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Remove-DynamicDistributionGroup"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Set-ADServerSettings"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Set-OrganizationConfig"} | remove-managementroleentry -confirm:$false
get-managementrole "MyDistManagers" | get-managementroleentry | where {$_.name -like "Write-AdminAuditLog"} | remove-managementroleentry -confirm:$false

This results in a new Management Role, which has the required management role entries to operate the Outlook Dialog box to add/remove distribution group members.

Now, we need to do two more things to begin to manage Groups with Groups…

The first, is to create a Management Scope, which will limit any permissions to a specific subset of objects. As we want to manage a Distribution Group, we can create a scope based on this group

For instance, we want to create a scope to manage the “Distribution@Company.com” distribution list. We can run the following command:

New-ManagementScope –Name “Scope to Manage Distribution@company.com” –recipientRestrictionFilter {PrimarySMTPAddress –eq Distribution@company.com}

We have our scope, so now we can join our Management Role with our management scope, to allow another group “Managers@company.com” to manage this distribution group

New-ManagementRoleAssignment -name "Group to manage Distribution@Company.com" -SecurityGroup Managers@company.com -role "MyDistManagers" -customrecipientwritescope "Scope to manage Distribution@company.com"

And now, members of “Managers@company.com” are allowed to manage the membership of Distribution@company.com using Outlook, and any changes to Managers@company.com will be reflected as soon as AD replication is complete, rather than after the Mode3 script has been run .

Please be aware that this method of managing groups has been tested only in my test lab , and as such should be thoroughly tested before use in your production environments. If you have a large number of groups, I would still suggest using the “Official” method from the Exchange Team Blog above. But.. for a small number of groups that “Have” to be manageable quickly, this is certainly an alternative that should work.

Plus, its a great way to think about how RBAC works under the hood!!

Matt

Custom RBAC Management Roles–Part 2

Matthew Abraham — Sun, 04 Dec 2011 13:56:41 GMT

In a previous post, I explained how to create a Custom RBAC role which removes certain abilities from the Administrative team. A comment was posted asking how to do the opposite, and create a role group with only certain cmdlets available, for an application to manage mobile devices. Here is the request:

Could you please assist me to create a new RBAC role group with permissions to the below powershell cmd-lets?
Get-MailboxGet-CASMailboxGet-ActiveSyncDeviceStatisticsSet-CASMailboxClear-ActiveSyncDevice (Remote Wipe)Remove-ActiveSyncDeviceGet-ActiveSyncMailboxPolicySet-ActiveSyncMailboxPolicyNew-ActiveSyncMailboxPolicyRemove-ActiveSyncMailboxPolicyGet-MailboxServerGet-ActiveSyncOrganizationSettings

The first step in working on this, is choosing the appropriate parent management roles. Now, all custom management roles must be based on a parent role, and cmdlets and parameters can be removed in the child role. Cmdlets which do not exist in the parent role, cannot be added later. Therefore, we must begin by finding which Built-in management roles contain these cmdlets. This can be done with the Get-ManagementRoleEntry cmdlet.

For each cmdlet above, we run Get-ManagementRoleEntry *\CmdletName which will give us an output like so

By repeating this command for all of the above cmdlets, we can see that we will need to create custom versions of the following built in role groups

Mail Recipients
Recipient Policies
Exchange Servers
Organization Client Access

From here, we can create child groups based on these parent roles, using the New-ManagementRole cmdlet.

We run four commands, to create our groups.

New-ManagementRole “Mail Recipients Mobile Devices” –Parent “Mail Recipients”
New-ManagementRole “Recipient Policies Mobile Devices” –Parent “Recipient Policies”
New-ManagementRole “Exchange Servers Mobile Devices” –Parent “Exchange Servers”
New-ManagementRole “Organization Client Access Mobile Devices” –Parent “Organization Client Access”

Now we have our Custom Roles created, (with descriptive names so we know later what they are for) we can start to remove the unwanted cmdlets.

To do this, we use the syntax posted in the last blog post.

Get-ManagementRole "Recipient Policies Mobile Devices" | Get-ManagementRoleEntry | Where {$_.Name -like "Get-DetailsTemplate”} | Remove-ManagementRoleEntry

We repeat this for all the unwanted cmdlets in all four new groups

We can then create our custom Role Group, containing these four new management roles.

To start, we run “New-RoleGroup “Mobile Device Management” to create the role group.

Then we can run New-ManagementRoleAssignment –SecurityGroup “Mobile Device Management” –Role “Mail Recipients Mobile Devices” to assign the new management role to the role group. We then repeat this for the remaining four roles.

We now have a role group created with a custom set of RBAC permissions. This should be fully tested in the lab to ensure that the service account for the mobile device software is able to run sufficiently using these permissions. These steps can be used to create other custom role groups if needed.

PowerShell for Exchange 2010–Cheat Sheet!

Matthew Abraham — Fri, 21 Oct 2011 08:27:14 GMT

When working with customers, everyone who is new to PowerShell finds it to be an amazing idea, but very daunting. Once you start using it, you will pick up the syntax and how to structure your commands.

However, it can take a while to get to know which cmdlet to use, and what each cmdlet can do!

So, I have created a “Cheat Sheet” with a list of some of the most important Exchange 2010 PowerShell Cmdlets. A lot of these can also be used with Exchange 2007 as well!

Please do let me know what you think in the comments below!