Jonny 的个人资料Live@edu日志列表 工具 帮助

日志


5月21日

Open another user’s mailbox in Outlook Live

I seem to be on a roll today with the whole mailbox permission setting thing in PowerShell… anyway this is my last post on this for the time being… I would be interested in hearing some thoughts from others here on the potential applications.

A lot of IT Managers in the schools and institutions I talk to want to know how they can see the contents of a user’s mailbox.  The reasons for this vary, but mainly it boils down to doing investigations and protecting kids from cyber-bullying or harmful content in email.  By default, a user mailbox is private and no one else can open it to view the contents unless the individual user grants these permissions.  An administrator however is all-powerful, and can grant themselves the necessary permissions, and then simply use OWA or Outlook 2007 to look at whatever they like in someone else’s account.

To grant permissions, first of all, connect to the Outlook Live service using PowerShell, then run the following command:

add-MailboxPermission -Identity JennyA -User admin -AccessRights fullaccess

… in this case, JennyA is the mailbox that the permissions are being modified on, and Admin is the account that is getting the permissions.

An admin can then look at this mail box using OWA for example.  To open another mailbox in OWA, click the drop-down arrow to the right of the Logged On user at the top right of the screen, and enter the alias of the mailbox you want to look at:

image

Once you are done with the investigation, you can remove the permissions again.

remove-MailboxPermission -Identity jennya -User admin -AccessRights fullaccess

Jonny

Setting an inbox rule for a mailbox using PowerShell

I was talking to a US East Coast Higher Education institution yesterday that is currently in the process of rolling out Outlook Live.  They intend doing a hard switch over of the service behind the existing student email addresses, and one thing they also wanted to retain were redirection rules that the students had set up… they have all of the details for this on a per-address level.  This objective can be achieved through PowerShell scripting… what follows are the component commands to use.

In Outlook Live, inbox rules are set on a per-mailbox basis… and this is something that users would normally configure manually through Outlook 2007 or OWA.  An administrator can however grant themselves with access to a mailbox, and then proceed to set up rules on the end-user’s behalf.  In this example, I am using JennyA as the mailbox to configure, and Admin as the mailbox admin.  JennyA is redirecting her mail to her personal Hotmail account.

First of all, as an admin, you need to grant yourself full access rights to the mailbox:

add-MailboxPermission -Identity jennya -User admin -AccessRights fullaccess

Then add the new inbox rule to

new-inboxrule -name "Redirect to personal hotmail" -mailbox jennya -redirectto jennya@hotmail.com

You will see something like this:

image

 

Finally, remove the admin’s access rights

remove-MailboxPermission -Identity jennya -User admin -AccessRights fullaccess

So that is it…enjoy!

Jonny

Using PowerShell to set a Mailbox Timezone

A question I get asked quite often by Outlook Live administrators is if it is possible to programmatically set the timezone on a mailbox.  The scenario is that a student has not set it right when they first logged in, and they may lack the knowledge to set it to what it should be.  This can lead to help desk calls if students get confused when their calendar (for example) does not align with what they expect the time to be.

A timezone for a mailbox can be viewed and set through PowerShell.  In the example below, JennyA is the user, and Admin is the Exchange Organization Administrator.

First of all, as an admin, you need to grant yourself full access rights to the mailbox:

add-MailboxPermission -Identity jennya -User admin -AccessRights fullaccess

Then, you can check to see what the TimeZone is currently set to:

get-MailboxRegionalConfiguration -identity jennya

You will see a result like the following:

image

Then, you can change the TimeZone to something else…let’s say Pacific Standard Time

set-MailboxRegionalConfiguration -identity jennya -TimeZone "Pacific Standard Time"

Finally, remove the full access privileges from the admin account:

Remove-MailboxPermission -Identity jennya -User admin -AccessRights fullaccess

If you need to do this en masse, you could of course write a PowerShell script to do this that works in conjunction with a CSV file containing the mailboxes you want to adjust.  The timezones are all referenced with their full name.  If you don’t know what to use, manually set a time zone in OWA, and then use PowerShell to see what it is called.

That’s it!

Jonny

Disable the Instant Messaging Widget in Outlook Live

With the release of Outlook Live back in Feb this year, we added in a little Live Messenger widget that allowed users to manage connections with their Messenger contacts, and to kick off basic chat sessions… this is a service that has proven popular in some quarters with students.

image image

Some schools however dislike the use of messenger, and would prefer to have this widget removed… this can be achieved in the all powerful PowerShell (thanks to Kumarswamy Valegerepura from the Exchange front end team for providing some assistance here!)

This is a setting that is part of the OWA Mailbox Policy.  There are potentially 2 policies to modify here, the DefaultMailboxPlan and the GalDisabledMailboxPlan, if you are making use of both, if you are only making use of one of these plans, please be sure to modify the correct one.

Anyway, after connecting to Outlook Live with Powershell, run the following command[s]:

# to modify Default Mailbox Plan
set-owamailboxpolicy -identity OwaMailboxPolicy-DefaultMailboxPlan -instantmessagingenabled:$false

#to modify Gal Disabled Mailbox Plan
set-owamailboxpolicy -identity OwaMailboxPolicy-GalDisabledMailboxPlan -instantmessagingenabled:$false

You should then log into http://outlook.com to see the outcome… the widget should be gone.

You can also confirm the setting in PowerShell by entering:

# to see Default Mailbox Plan IM settings
get-owamailboxpolicy -organization:"contososchool.info" -identity:"OwaMailboxPolicy-DefaultMailboxPlan" |  fl *instant*

or

# to see Gal Disabled Mailbox Plan IM settings

get-owamailboxpolicy -organization:"contososchool.info" -identity:"OwaMailboxPolicy-GalDisabledMailboxPlan" |  fl *instant*

Enjoy!

Jonny

5月18日

New Live@edu group set up focusing on K-12 (Primary and Secondary :) )

A new group (http://k12live.groups.live.com/) has been set up recently, and in it, you can find the genesis of some conversations dealing with the particular concerns of that segment.

Check it out!

Jonny

New Live@edu program site and enrollment process launches

We have just launched our new Live@edu program site: http://www.microsoft.com/liveatedu/free-hosted-student-email.aspx

Some key new features (from my point of view):

  • Better layout – the key components of the offering are now more apparent I think.
  • A load of mini-demos and overviews – if you are like me, and like to watch demos rather than read about them, you will like what we have done I hope (expand the sections to see them).
  • A revised FAQ - more clearly differentiates between Outlook Live and Hotmail, and is more extensive than before.
  • A completely revised enrollment process and management portal… read more below:

New Enrollment Forms – The enrollment process is greatly simplified to streamline on-boarding.  The number of fields we ask for at this important point has been reduced from 46 to just 16, and some previously manual aspects of on-boarding are now automated.  The end result is that customer wait times for receipt of their Live@edu admin ID has been slashed from 48 hours to just 5 minutes!

Services Management Portal – The SMP is our new one-stop admin portal for the IT Pro that makes it even easier for them to administer their account and access critical tasks and information on the services.  This is currently only available to new customers, but existing customers will get this in a matter of weeks.

We would appreciate your feedback… so send on any thoughts.

Jonny

5月7日

How To Prevent Users From Creating Distribution Groups(aka Public Groups) Or From Having Access to the Groups Page Entirely

Following on from a previous post on restricting users from modifying their Outlook Live properties, another one of our escalation engineers, Kevyn Pietsch, has weighed in with more great content!  Over to Kevyn!

---

Please note: The following information is specific to R3, and may change during future updates of the product.

In Outlook Live, one of the features that helps promote collaboration between students is the capability users have been given to create and manage their own Distribution Groups(DGs; aka Public Groups), as well as manage their membership in other DGs, via the Exchange Control Panel(ECP). Tenant administrators(TAs) have asked for guidance on how to control what users can do in this area. One example we've heard TAs ask about is how to prevent students from creating their own DGs. This blog discusses how to use Role Based Access Control(RBAC) to prevent users from being able to create DGs, as well as how to completely remove their abilility to access the Groups page, in the ECP.

By default, users are given access to manage DGs they belong to, and DGs they own, via two default RBAC roles/role assignments. The roles define what a student can view/modify for their own account. In order to determine the names of the two default DG roles/role assignments, you can run the following RPS command:

Get-ManagementRoleAssignment -User DefaultMailboxPlan | where {$_.name -like "MyDistributionGroup*"} | fl Name,Role

In a default RBAC setup, the output will be as follows:

Name : MyDistributionGroups-MailboxPlan-DefaultMailboxPlan<tenant specific alphanumeric sequence>

Role : <domain name>\MyDistributionGroups_DefaultMailboxPlan

Name : MyDistributionGroupMembership-MailboxPlan-DefaultMailboxPlan<tenant specific numeric sequence>

Role : <domain name>\MyDistributionGroupMembership_DefaultMailboxPlan

The roles listed above are comprised of the cmdlets(aka tasks) listed in the following tables. The parameters of each of the cmdlets is not listed in the tables, but can be determined, per cmdlet, by running the following command:

$(Get-ManagementRoleEntry <role name>\<cmdlet name>).parameters

Role: <domain name>\MyDistributionGroups_DefaultMailboxPlan

Cmdlet Name

Update-DistributionGroupMember

Set-Group

Set-DynamicDistributionGroup

Set-DistributionGroup

Remove-DistributionGroupMember

Remove-DistributionGroup

New-DistributionGroup

Get-User

Get-Recipient

Get-MessageLatencyReport

Get-Mailbox

Get-MailUser

Get-MailContact

Get-Group

Get-DistributionGroupMember

Get-DistributionGroup

Get-Contact

Add-DistributionGroupMember

Role: <domain name>\MyDistributionGroupMembership_DefaultMailboxPlan

Cmdlet Name

Remove-DistributionGroupMember

Get-User

Get-Recipient

Get-MessageLatencyReport

Get-Mailbox

Get-MailUser

Get-MailContact

Get-Group

Get-DistributionGroupMember

Get-DistributionGroup

Get-Contact

Add-DistributionGroupMember


Removing users' ability to create DGs

clip_image002

Please note that the following information assumes a default RBAC setup for the DG roles/role assignments.

In order to prevent users from being able to create DGs, the New-DistributionGroup cmdlet must be removed from the list of cmdlets they have access to. Since default roles(aka parent roles), such as the DG roles listed earlier, cannot be modified, a customized copy of the <domain name>\MyDistributionGroups_DefaultMailboxPlan parent role must be modified and assigned to the users via a new role assignment. Also, the role assignment that assigns the <domain name>\MyDistributionGroups_DefaultMailboxPlan parent role to users, via the DefaultMailboxPlan security context, must be removed. This is because the cmdlets/parameters in the roles that are assigned to users are cumulative. The steps to do this are as follows:

1. Make a customized copy of the <domain name>\MyDistributionGroups_DefaultMailboxPlan parent role by running the following RPS command:

New-ManagementRole -Name Limited_MyDGs_DefaultMailboxPlan -Parent MyDistributionGroups_DefaultMailboxPlan

Note: When using a parent role name in an RPS command, including the <domain name> part of the role name is optional. For this example, when specifying the parent role name in the -Parent paramter, I have left out the <domain name> part of the parent role name. Also, for this example, I used the customized role name of Limited_MyDGs_DefaultMailboxPlan. It is recommended that a memorable naming convention be used for the new role/role assignment names.

2. Remove the New-DistributionGroup cmdlet from the Limited_MyDGs_DefaultMailboxPlan role by running the following RPS command:

Remove-ManagementRoleEntry -Identity Limited_MyDGs_DefaultMailboxPlan\New-DistributionGroup

3. Create the new role assignment to assign the Limited_MyDGs_DefaultMailboxPlan role to users, via the DefaultMailboxPlan security context, via the following RPS command:

New-ManagementRoleAssignment -Name Limited_MyDGs_DefaultMailboxPlan_RoleAssignment -Role Limited_MyDGs_DefaultMailboxPlan -User DefaultMailboxPlan

Note: For this example, I used Limited_MyDGs_DefaultMailboxPlan_RoleAssignment as the name of the new role assignment that assigns the Limited_MyDGs_DefaultMailboxPlan customized role to the users, via the DefaultMailboxPlan security context.

4. Determine the name of the default role assignment that assigns the <domain name>\MyDistributionGroups_DefaultMailboxPlan parent role to the users via the following RPS command:

Get-ManagementRoleAssignment -User DefaultMailboxPlan | where {$_.name -like "MyDistributionGroups*"} | fl Name,Role

5. Remove the default role assignment from the users by running the following RPS command:

Remove-ManagementRoleAssignment -Name <default role assignment name from step 4>

Removing access to the Groups page

clip_image004

In order to remove access to the Groups page, you simply remove both of the default DG role assignments by going through the following steps:

1. Determine the names of the DG role assignments that assigned the roles to the users(via the DefaultMailboxPlan), via the following RPS command:

Get-ManagementRoleAssignment -User DefaultMailboxPlan | where {$_.name -like "MyDistributionGroup*"} | fl Name

2. Remove the two default DG role assignments by running the following command against both of the role assignment names from step 1, via the following RPS command:

Remove-ManagementRoleAssignment -Identity <role assignment name>

5月6日

PowerShell and Outlook Live on Windows 7 RC Build

In the last few days we released the Release Candidate build of Windows 7… great to see, and I am looking forward to seeing our education customers adopt this new OS.

Some customers might be aware that Windows 7 ships with the very latest PowerShell CTP (Community Technology Preview) preinstalled.  Conveniently on the Windows 7 beta build (Build 7000) that we shipped a few months ago, the version of PowerShell was the correct version that worked with Outlook Live.  On the RC Build of Windows 7 there is a different version of the CTP, and right now this does NOT work with Outlook Live.

So the upshot is that you should either continue to use Vista SP1 or Windows Server 2008 with PowerShell for best results.  Follow the instructions here: http://help.outlook.com/en-us/140/cc546278.aspx

Jonny

5月4日

Exchange Web Services Managed API beta available

A week or so ago, the Exchange team announced that they had released the Web Services API for Exchange; this works with Outlook Live which is Exchange 2010 based.

The upshot of all of this is that a load of new developer scenarios open up to our Live@edu customers like programmatically creating appointments, sending automated emails, updating contacts, and more.

There has been some discussion on this over on the Live@edu community group on this thread… I am hoping that there will be a lot more in the coming months as customers start getting to grips with what they can do here.

Jason Henderson from the Exchange team had the following advice to offer to customers on the discussion group:

---

Some keys to remember when using it:

1. Make sure you first accept the terms of use for the account whose credentials you are using to logon

2. Make sure you call AutoDiscover to find the URL for the specific account that you are using to get the correct URL to use for logon. 

3. Make sure the username is in username@domain.edu format see the code below for an example

//Instantiate the service with Exchange 2007 SP1 schema
ExchangeService Service = new ExchangeService(ExchangeVersion.Exchange2007_SP1);
Service.Credentials = new WebCredentials("jason@contoso.edu", "password");
Service.AutodiscoverUrl("jason@contoso.edu");

//Bind to the inbox folder and retrieve all properties
Folder inbox = Folder.Bind(Service, WellKnownFolderName.Inbox);

//Write out the total # of items in the inbox
Console.WriteLine(inbox.TotalCount);

---

Special kudos will be given to someone that can provide some code snippets demonstrating how to inject calendar items from a timetabling application into a bunch of student calendars :)

Jonny