I was talking to one of our great Outlook Live support engineers, Roman Maddox, recently, and he was telling me that a fairly common request we get from customers has to do with controlling what users can change about themselves in the Shared Address Book in Outlook Live.  We actually document this scenario as an example of Role Based Access Controls and Mailbox Plans quite extensively… but Roman kindly provided some more content for me to post.

---

The question often comes up around what needs to be done to prevent a student from modifying their Account settings, yet still allowing an Alumni to modify theirs. Since moving to the current release in the Outlook.com datacenter, new PowerShell cmdlets have become available that facilitate the creation of security groups, with which a Tenant administrator can put together a new RBAC role, customize the cmdlets available to the role, and then create a new Role assignment that uses the security group to specify which users are able to perform certain tasks.

Previously in the datacenter, it was only possible to prevent a student from changing account settings by denying them access to the Control Panel (ECP) UI element that handles editing the properties.

Before	After :)

In the current release, however, it is possible to deny access to individual properties in the UI element in ECP.  The details are found in http://help.outlook.com/en-us/140/dd335876.aspx.

Specific Example Steps for creating the roles/assignments/security groups to accomplish your task:

In this case, there are two groups of students that have differing requirements. Accordingly, we will need to create two security groups:

New-DistributionGroup <NameforNoChangeGroup> -type: security

New-DistributionGroup <NameforChangeGroup>  -type: security

Groups of -type:security MUST be created via Remote PowerShell (RPS) at this point.  There is no way to modify an existing group to be a security group.  To use Remote Powershell, refer to the following article http://help.outlook.com/en-us/140/cc546278.aspx.

Once the groups are created, we can modify their membership from the ECP – the new groups will show up in the list of groups the TA can manage.  You can also use a CSV file according to the following posting http://liveatedu.spaces.live.com/blog/cns!C76EAE4D4A509FBD!885.entry to bulk add users to a security group.

Now that we have the security context for the role assignments, we need to create/customize the roles for the cmdlets we want the users to be able to use.  We will need one customized role for the group we want to prevent from changing their account settings, while we can still use the existing role for the other group.

To see what roles are available, run Get-Management Role | ft name

To impact Account settings, either MyOptions_DefaultMailboxPlan or MyOptions_GalDisabledMailboxPlan should be used as the Parent role.  For info on Mailbox plans, refer to articles http://help.outlook.com/en-us/140/dd229067.aspx and http://help.outlook.com/en-us/140/dd335876.aspx.

For example purposes, we will use the Default Mailbox plan:

New-ManagementRole -Name <your role name here> –Parent <YourDomainNameHere>\myoptions_defaultmailboxplan

Example:

New-ManagementRole -Name limitedmyoptions_defaultmailboxplan -Parent mydomain.com\myoptions_defaultmailboxplan

Once you have created the new role, we need to remove cmdlets/parameters from it.  In this scenario, we can either deny the students the ability to edit any of their account settings, or individual parameters (Note that when running the cmdlets, you may be prompted to confirm the action):

Remove-ManagementRoleEntry limitedmyoptions_defaultmailboxplan\Set-User   

The preceding will prevent editing any of the parameters, or, we can deny the ability to edit individual parameters:

Set-ManagementRoleEntry limitedmyoptions_defaultmailboxplan\Set-User -Parameters <parameter> -RemoveParameter

Set-ManagementRoleEntry limitedmyoptions_defaultmailboxplan\Set-User -Parameters WorkPhone –RemoveParameter

For account settings, the following parameters can be modified, unless they are required/special fields. We found that a required field can’t be removed, but the cmdlet won’t tell you this…

We can remove one or several parameters, depending on the desired effect.

Once this is done, we need to then remove the existing management role assignment so that we can replace it with the custom role/assignment:

First, run “Get-ManagementRoleAssignment | ft name,role” to find the name of the role assignment to be removed, which should be in the form of “MyOptions-MailboxPlan-DefaultMailboxPlanxxxx…..”

Next run Remove-ManagementRoleAssignment <your default role assignment name here>

At this point, we can create the new role assignment which should make the changes effective for the users:

New-ManagementRoleAssignment -Name <RoleAssignmentName> -Role <limited role created for this scenario> -user <your domain name>\<Security group created for limited users>

Example

New-ManagementRoleAssignment -Name limitedmyoptions-DefaultMailboxPlan -Role limitedmyoptions_defaultmailboxplan -user cloudywithachanceofehlo.info\NochangeGrp4Myoptions

We should now be able to log in with a user account that has been assigned to the “<NameforNoChangeGroup>” security group, and note that the user is neither able to edit any of their account settings, nor they will see the removed parameters.

There are fewer steps for getting the alumni setup:

New-ManagementRoleAssignment -Name <memorable name> -Role MyOptions_DefaultMailboxPlan -user <your domain>\“<NameforNoChangeGroup>”

Essentially, we are assigning the existing role to the security group we created earlier for students who will be able to modify their own account information.

Summary

We have created two email enabled security groups, one new management role that we subsequently customized by either removing the Set-User cmdlet, or individual parameters of the Set-User cmdlet, and two management role assignments that allow us to apply a different ECP experience to differing groups of students.

I would encourage the practice of copying all the cmdlet syntax into Notepad or the equivalent to make sure the group, role, role assignment names, etc. are how they need to be before running through the steps.  I would also encourage copying the name/syntax used for any role assignment/role entry modified or removed, so that if later the need arises to revert them back, this should hopefully make that process quicker.  I would also advocate testing this with a limited number of accounts before rolling it out more broadly – we found in testing that there was in certain instances a time lag between running the cmdlet, and the corresponding UI changes showing up.

This should get you started, and we plan to have additional postings on related RBAC topics soon.

-Roman

As part of the recent upgrade to Outlook Live R3, PowerShell V2 CTP3 will be required to connect to Outlook Live beginning on Monday (4/13/09).  PowerShell V2 CTP2 will no longer establish a connection and will result in a failure notification.

To connect to Outlook Live, please download and install the updated Windows PowerShell v2 CTP3 and WinRM 2.0 CTP3. Instructions here.  This new version has some changes to the syntax used, so please review the technical documentation for guidance.

Thanks!

Jonny

Updated to reflect new functionality: 5/20/2009

One of our Exchange Escalation Engineers, Brad Hughes, in conjunction with one of our PMs, Shawn McGrath, has just launched a new tool that can be used by customers to test the internet-facing aspects of an Exchange Environment; it is called the Exchange Server Remote Connectivity Analyzer, and it is described on the Exchange Team blog.

I took one look at this and then tried it straight away with my Outlook Live tenant.  The tool is in beta, but it already provides some useful data if you are troubleshooting a connectivity issue.  The following table details the various tests that you can run today, and with notes on my experiences with Outlook Live.

I checked with the guys behind this, and found that they were already aware of the Exchange 14 issue when checking Outlook 2007 Autodiscover Connectivity… but that there is a fix in the works very soon… along with support for further Client Access methods such as OWA.

Here is what a typical result looks like… results sample from an Activesync connectivity test:

Enjoy!
Jonny

I spent yesterday evening messing around with the various things we support as far as Outlook Live and the ActiveSync protocol is concerned.  This was prompted by a question that came up on the Live@edu Community Group about what kind of reporting we can do against our service related to users of ActiveSync enabled devices.  I had not even set up such a device with Outlook Live before, so I decided to investigate some more… what follows is a random list of stuff I did… while watching Jack Bauer save civilization from an imminent threat for a 7th time.

Set up a Windows Mobile 6.0 Emulator on my desktop

Not a lot of folks know this (outside the developer community perhaps), but we offer a range of Emulator Images that you can install on your machine for testing purposes…  I installed a US English version… unfortunately we do not supply a Northern Irish one.  I set it up to use my local internet connection to access the web, and then set up the mail client to use my Outlook Live account.  We provide directions for a number of different service providers and models of phone.  I then ran a sync over my ‘GPRS’ network.  Below is what it looked like…. cool!

Explored how an end user can monitor and manage the partnership

If a user logs in to OWA, they can do the following (described here):

• see the details of the partnership in Mail Options
• pull back some sync data
• request that a log of the sync data is sent to their phone
• Delete a sync partnership
• Remotely wipe a device – say if it is lost or stolen

Explored the kinds of things an Administrator can do with PowerShell

So this is the thing I had not really looked at until yesterday, but I was happy to find that there is support for a lot of useful things… here are some examples that I tried:

Anyway there are loads, and someone that is proficient in the art of scripting could easily pipe some of these cmdlets together to build some useful reports… kudos to my friend in the CESI Group, France for supplying a nice cmdlet that generates a useful HTML report of all connected devices using ActiveSync:

Get-ActiveSyncDevice | Select UserDisplayName,DeviceType,DeviceModel,DeviceOS,OSLanguage,Imei,FirstSyncTime,LastUpdateTime | sort-object LastUpdateTime | ConvertTo-HTML | Out-File "c:\DevicePhone.html"

Don’t forget, you can also submit these one-liners to our Community Scripts Centre.

Bye for now!

Jonny