Exchange 2013 Anti-Malware Protection

Since there will be no Forefront protection for Exchange Server 2013 to handle spam and other bad things coming in with mail from Internet, Exchange admins must use something else to block those bad things, but what to use?

For those organizations that use Exchange Edge and Forefront protection for Exchange on it can continue to use that together with Exchange server 2013.
There is no Exchange 2013 Edge server yet, but hopefully it will be in the future.

Another option that many organizations already use is to leverage something outside of Exchange for hygiene. This software is deployed on regular servers or as an appliance and some is used as a service on Internet, and most of the time these solutions costs money.

Microsoft did not leave organizations completely out in the dark by removing forefront for Exchange. They moved some if it’s functionality into Exchange.
First we have to regular transport anti-spam agents that have its legacy from Exchange 2003 and IMF (Intelligent Message Filter). They of course have evolved and some organizations use them today with their Exchange 2007 and Exchange 2010.
Installation is done with help of a powershell script “install-AntispamAgents.ps1” located in the scripts subfolder in the Exchange installation. Difference with Exchange 2013 compared to earlier versions is that in Exchange 2013 there is no GUI to configure those agents and you must leverage powershell.
Those agents are as stated anti-spam agents, http://technet.microsoft.com/en-us/library/jj218660.aspx . They have been around for years and are configured in the same way as before so one thing you definitely should do is to use safelist aggregation, http://anewmessagehasarrived.blogspot.se/2008/04/outlook-safelist-aggregation.html but configuration of the anti-spam agents is a story for it self.

Secondly the malware filtering piece of Forefront for Exchange moved into Exchange itself, http://technet.microsoft.com/en-us/library/jj150547.aspx. If you have an Exchange 2010 with forefront for Exchange installed and an Exchange 2013 you will see the same folder structure “C:\Program Files (x86)\Microsoft Forefront Protection for Exchange Server” and “C:\Program Files\Microsoft\Exchange Server\V15\FIP-FS”
This is something that you have to enable and configure after installation of Exchange and are all done with powershell commands.
To enable the malware agent who is disabled by default, use the powershell script “Enable-AntimalwareScanning.ps1”. This script will not only enable the malware agent but also configure regular updates, restart the transport service etc. to get everything running. Default automatic update check for definitions will every 60 minutes. You can verify when and what version of the engine and definitions is in use with “Get-EngineUpdateInformation” or if you want to manually check for updates, use the powershell script “Update-MalwareFilteringServer.ps1” that basically is a wrapper around the “Start-EngineUpdate” powershell command.

When this is done, you should have a look at the default malware policy and possibly alter the configuration, http://technet.microsoft.com/en-us/library/jj150576.aspx.
Think about the available options for a while before changing them, especially where to send notifications and to whom otherwise you can create a mail storm of notifications.

If the built-in anti-spam agents and malware protection is good enough for your organization is something you have to decide. There is little information about how the malware piece is performing in real life since very few organizations don’t yet run Exchange 2013

Exchange 2010 Service Pack 2 Rollup 5 version 2

Some weeks ago Microsoft released rollup 5 but it was withdrawn quickly due to some reported issues. Now Microsoft has released version 2.

It contains several bug fixes as expected KB 2785908 but also contain fix for the security bulletin MS12-080 which is rated Critical Microsoft Security Bulletin MS12-080

Download link for Update Rollup 5-v2 for Exchange Server 2010 Service Pack 2 (KB2785908)

Exchange 2010 Service Pack 2 Update Rollup 5

It is time again for another rollup for Exchange 2010. This is number 5 for Service Pack 2.

Read the full description here and download it here

Patching Exchange 2010 servers being member of a Database Availability Group (DAG)

For administrators that come from a non-clustered environment to a clustered one must learn that patching is done different. Non-clustered servers often simply can be set to use WSUS or any other patching product with simply install patches and then most likely a restart of services or a reboot of the windows box. With clustering solution this is not best practice and behaving this way often break something in the process.
The preferred way of patching clustered servers is to move resources off the node you’re about to patch and then apply patches. This is a manual process and often takes time. Positive side is that administrators have complete visibility of the process and sees if anything don’t work as expected and can take action on the failed node while other nodes of cluster is still maintain service to users. This scenario also let administrator work at regular office hours instead of working late at night on patching-day or weekends.
Exchange 2010 is delivered with some scripts that help administrators manage all this manually.
In the scripts directory, there are 3 scripts. StartDagServerMaintenance.ps1, StopDagServerMaintenance.ps1 and RedistributeActiveDatabases.ps1
Start on the first node by running StartDagServerMaintenance.ps1 –serverName <node name>
This will move databases from the first node to another node in the DAG and also move the Cluster Group to another node if needed, to maintain quorum and have the Primary Active Manager online which is important. It will not just move things off the first node, it will also reconfigure some parameters to stop databases moving back if a failure occur on another node during maintenance. This is the same for the “Cluster Group” resource.
Now you can patch and do other maintenance on the first node as needed without it coming online.
For it to come online after maintenance you run StopDagServerMaintenance –serverName < node name>
This will remove configuration to stop databases move to the server. So from here on the server is free to host active databases again or running the Primary Active Manager. Script will not move any databases back to the server, it will just configure server to be a possible owner of databases.
Next step is to repeat all this for any other node in your DAG. If you have a large dag then it is possible to patch multiple servers at the same time. But be careful to maintain quorum, otherwise things will break.
As a last step when all servers are back online in normal state is to use the last script RedistributeActiveDatabases
This script has several parameters but the one you want to use now is -BalanceDbsByActivationPreference
When run, databases will be moved to the mailbox database server with the lowest activationpreference set on each individual database so hopefully it is set already in a way that suits your environment.
All these steps takes time and is manual, you should also verify between each step that replication is working and you don’t do backup at the same time. Replication can be verified with Get-MailboxDatabaseCopyStatus cmdlet.
What happens if you simply apply patches to server being member of a DAG and reboot it afterwards ?
In theory nothing should stop your DAG from serving users. This is also what I experience from real live as long as you don’t reboot multiple servers at the same time and loose quorum, but what sometime happens is that replication and Indexing breaks, leaving some tasks for admins to clean up later.
Smaller organizations often don’t have the time to babysit servers while patching them, they just want to configure patches in WSUS and they will automatically be applied during the night without anything bad happen.
To make this work you must first configure windows update client on server to not to apply patches at the same time. Next I have created a script that you must schedule to run a little bit ahead of time when Windows Update do its work. Let say you configure Windows Update to apply patches at 1 am in the morning, then schedule the script to run 30 to 60 minutes before.
On next node in your DAG you schedule Windows Update to apply patches at 3am, so on this server schedule the script to run sometime between 2 and 2.30 am.
Script will do about the same thing as the start/stopdagservermaintenance script but in a slightly different way. It will not configure databases and servers to be blocked from activation. It will verify and not move any databases while a backup is running. It will also try to fix some errors such as content index or replication being in a failed state. Fixing error should not be needed in a perfect world but can happen. Script is just doing some very basic things and it is up to you to change what you think is good action to different situations.
Script loops through looking for database and replication health state. If something is not good it will try to apply action to it and also try to move databases to another node in your DAG. Between each loop there is pause for a minute to let replication and other things to catch up and come to a steady state.
It will not loop forever, but has a limit of ten times. I figured that, if actions could not be performed with 10 tries it is not worth trying anymore. You probably have something worse to handle than just a script handling a little glitch in your DAG.
Parameters that you probably need to set to suit your environment is the sleep time on line 120 and number of loops on line 124, copy and replayqueuelength on row 110 need to be set to work correctly in your organization.
There is a lot of IF’s between line 23 and 110 trying to handle different situations. Look through these and see if they are OK for you.
Script doesn’t have any special error handling or output. I figured if it scheduled at nighttime there isn’t much need for output anyway. Logging can be added for admins to look at later.
Why not schedule the start/stopdagservermaintence script? This can of course be a viable solution. Problem here as I see it is that it will set servers and databases to not become active automatically and you want to set everything back to automatic once each server is patched. The problem is that you don’t know how long time each server take to patch so picking the correct schedule could be tricky and if only have a small DAG with 2 servers you want them to be available as much time as possible. My script also tries to correct some issues before move databases to another node.
Script is on my Skydrive

Exchange re-release update rollups

Exchange2010 and 2007 has recently re-released a couple of updates which are called version2 of the previously released rollups. Confusing ? perhaps another blog post will clear the fog http://blogs.technet.com/b/exchange/archive/2012/10/09/re-released-exchange-2010-and-exchange-2007-update-rollups.aspx

The big RTM

Exchange, Office and Lync development team has now reached what they think is a good and stable release to distribute it to customers, aka RTM. But hold your breath for a while since it will not be available for download today, but will be staged out to customers during the next few months.

The Exchange team announcement. http://blogs.technet.com/b/exchange/archive/2012/10/11/the-new-exchange-reaches-rtm.aspx

Lync team announcment http://blogs.technet.com/b/lync/archive/2012/10/11/lync-2013-is-finished.aspx

Office team announcment http://blogs.office.com/b/office-news/archive/2012/10/11/office-reaches-rtm.aspx

Patching time for Exchange

It is time again for Update rollups for Exchange.

Exchange 2010 is now on Service Pack 2 update rollup 4. Read KB 2706690 for more information what’s inside.
Download link is here

Exchange 2007 is now on Service Pack 3 update rollup 8, Read KB 273423 for more information what’s inside.
Download link is here

Happy patching.

Exchange Server 2013 preview

Microsoft about a month ago allowed people to download and try out next version of Exchange, dubbed Exchange server 2013.
I have played with it for a while and have some comments on what I think is good and bad.

If I refer to the Exchange team blog article http://blogs.technet.com/b/exchange/archive/2012/07/23/the-new-exchange.aspx

Reduced costs by optimizing for next generation of hardware
I think the reduced IO is good as focusing on design for upcoming hardware is also good even though not that many companies buy into the DAS story but instead still use different SAN technologies. This can be discussed for a very long time and both technologies have its advantages. I have done implementations with both DAS and SAN storage for Exchange and looking in the rear view mirror a lot of errors in Exchange storage has not been in the DAS area but with management error of the SAN storage/infrastructure. The reduced IO demand is of course good regardless of whatever storage you use.
Store.exe has now been rewritten in managed code and each database runs its own version of store.exe which make them more isolated from each other so if one crash the other DB’s will continue to run without interruption.
Yes. Exchange still uses the ESE database engine.

Significantly reduced operational overhead for high availability
Have you ever tried to do a site failover? There are some challenges and it will take time with verification between steps. Steps have been easier and work has been done in Exchange to make failovers a better experience for clients. One important thing is that Exchange only accepts client connection done by HTTPS/RPC, or in other words, Outlook Anywhere is used everywhere which simplifies namespace planning a lot. Easier configuration on Load Balancer where we now only need to configure for layer 4 affinity instead of using Layer 7 as in Exchange 2007/2010.
Exchange 2013 also has an additional service “Microsoft Exchange Health Manager” which will monitor many different aspect of Exchange and not only trigger alarms but will also take actions such as do database reseed, restart services etc.

Decrease the amount of time spent managing your system while maintaining control
Administration
In Exchange 2010 is done by either PowerShell or the rather slow Exchange Management Console. In Exchange 2013 there is no EMC, it is replaced by EAC (Exchange Administration Console), a web GUI based on ECP but with much more functionality than ECP. It is not that slow as the old EMC and perform rather well, the sad story is that it is using the Metro interface with sometimes hard to figure out icons and a lot of unused space on the screen.
If you need to do something more advanced or repetitive, you should of course switch to Exchange Management Shell which is still used in the background from EAC.
Don’t know if time administer your Exchange environment will be smaller with Exchange 2013 than it is today just because switching to webGUI.

Automatically protect Exchange availability from surges in traffic
This means that things going on inside Exchange database that don’t have to happen at once is given a lover priority and is performed at a later time freeing up resources for things that need to happen quickly.

Cloud on your terms
Not that much going on here compared to Exchange 2010 Service Pack 2 as I see it.

Automatically protect your email from malware
Exchange has now a service for malware protection, Microsoft Forefront Filtering Management Service (FMS). This gives organizations a descent built in protection from scratch. If you need something better you can install the good old anti-spam agents and if you need something even more sophisticated you ought to look outside Exchange to Exchange online protection with forefront or some non-Microsoft solution.

Protect your sensitive data and inform users of internal compliance policies with Data Loss Prevention (DLP) capabilities
DLP functionality is to block information from leave Exchange. The classic is to block email with credit card information, but you can of course define what information you don’t want to be sent to internet. For organizations that need this, this is very good.

Allow compliance officers to run In-Place eDiscovery across Exchange, SharePoint, and Lync – from a single interface
Exchange 2013 index engine is replaced with FAST, same as used in SharePoint. Levering FAST functionality administrators can search for information in Exchange and SharePoint from a single interface. Also very good for organizations which need to do eDiscovery.

Allow users to naturally work together – while compliance is applied behind the scenes
Remember that outlook has the ability to connect to a document library in SharePoint. Outlook still can do this but also group the document library together with a “site mailbox” in Exchange. For this to work automatically you need Outlook 2013, Exchange 2013 and SharePoint 2013 together with some configuration in SharePoint. Only time will tell if this is something people will use.

Modern Public Folders
There is not much news here except at the server side where Public folders now use the same replication technology we have been using in DAG’s in Exchange 2010, so no more replication messages with SMTP mail between public folder databases. There is migration path for this where admin some point in time decide to do the cutover from the old replication technology to the new one. This could be critical if you have a lot of public folders today and planning is a must. Once the cutover is done we can hopefully take advantage of a more stable and faster replication than the very old one used now. Public Folder data is after the migration maintained in public folder mailboxes which you can have multiple if you like.

OWA
OWA has as usual gone through a facelift. This time it also has been designed to work well on other devices than regular PC’s such as phones and devices with smaller screens. An offline version is also available but it has some prerequisite such as IE10.

Modern people search and bring all contacts together
makes is easier to find contacts from several sources without having the mess with duplicates and easier find the correct contact. This is a good thing for end user.

OWA canvas makes calendar more useful
This is a good one for users using OWA.

Application in OWA
Administrators can now install applications in OWA to make OWA extendable. Only time will tell what applications will be available and actually provide valuable to end users.

Other insight and thoughts
Architecture in Exchange has changed. Remember when Exchange 2007 was introduced it has split the installation in different roles. Now the thinking of roles has changed again and we have only Mailbox and Client Access role left. Mailbox role is now not only the old mailbox role with its databases but a complete installation of Exchange including Unified Messaging. Services you don’t want to run can simply be disabled. The new Client Access is not the same as the old CAS, it is much lighter and act as a proxy against the mailbox role. It is sometimes called Client Access Front End (CAFE). New CAS also have some transport ability, but it is the same here as for CAS, it is only proxy SMTP traffic back to the mailbox role. All this will make the new CAS much lighter and if you today have a bunch of Exchange 2010 CAS servers you can probably be fine with a much smaller number of new CAS servers. Traffic between CAS and mailbox is https which gives the system ability to have CAS and mailbox servers in different sites without users being redirected.

There exist no Exchange 2013 Edge server role yet and if you want to use Edge server role you have to wait a while or use 2010 SP3 Edge.

Exchange 2013 can be installed on either Windows 2008 R2 SP1 or the new Windows 2012. One good thing if we use Windows Server 2012 is that clustering functionality is built-in in the standard version of Windows (there is no Windows Server 2012 Enterprise edition) which is good for license cost.

Upgrades cannot be done by inserting a DVD and run setup. Upgrades is performed by installing Exchange 2013 in parallel with you current Exchange environment that must be either Exchange 2007 or 2010 so if you’re on Exchange 2003 or earlier versions, you must first upgrade to 2007 or 2010 and then to 2013.

Outlook clients is of course the best client with most functionality even though OWA is pretty close to Outlook 2013 which of course is the preferred client since several new server functions need new client to understand them, such as DLP and site mailboxes. Microsoft made some changes in both outlook 2003 and Exchange 2010 to make outlook 2003 work correctly but this will not happen with Exchange 2013. That means you need Outlook 2007/2010 or 2013.

Some of these things might change since this is only a preview of Exchange 2013 and Microsoft will provide us with more information all the way until the finished product. Until then you can read up on the TechNet documentation about Exchange 2013 http://technet.microsoft.com/en-us/library/bb124558(v=exchg.150)

Exchange 2013 preview

Interested in seeing next version of Exchange? Look no further than to Exchange 2013 evaluation resources where you can read up on what's new and download the preview.

Both Office 2013 and Lync 2013 also has a preview available Office 2013 preview and Lync 2013 preview

Exchange 2010 Service Pack2 Update Rollup 3

Microsoft released a new update for Exchange 2010.

Download link Update Rollup 3 for Exchange 2010 SP2 (KB2685289)

This one includes several good fixes, for example RPC Client Access Cross-Site connectivity issues and the annoying Synchronization of an organizational forms library fails

Read the complete list of fixes this rollup includes

Move mailbox to free up space in databases

Admins are from time to time doing mailbox moves. Reason could be several but the goal is often to create some white space in mailbox databases.

By moving mailboxes to a different database you think it will create "holes" in the source database, and that's true until you the source server is Exchange 2010 service pack 1. With Service Pack 1 the behavior changed to leave the data it the source database until it get cleaned up when the mailbox retention limit is reached. http://technet.microsoft.com/en-us/library/ff829913.aspx
Reason for the change is that mailbox data should be easily accessed in a catastrophic failure before having a proper backup of the target database.

But what if you really want to create some space in the database now?
You could change the mailbox retention timeout to low number of days or even zero days. This might not be suitable solution and then you have to clean up the left-overs manually.
Article above say that mailboxes is in a soft-deleted state so they can be found with this command.

Get-MailboxStatistics -Database <databasename> | where {$_.DisconnectReason -eq "SoftDeleted"}

To clean up, you use the cmdlet Remove-StoreMailbox.

To make it work you do this is to steps. First save the mailboxes you want to delete in a variable.

$mbxs = Get-MailboxStatistics -Database databasename_you_want_to_clean_up | where {$_.DisconnectReason -eq “SoftDeleted”}

and then you delete them

$mbxs | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState SoftDeleted -Confirm:$false}

This will trigger a process to clean up in the database and you can follow it creating whitespace with this command

Get-MailboxDatabase -Status | Sort-Object name | Format-Table Name, DatabaseSize, AvailableNewMailboxSpace

or for a specific database

Get-MailboxDatabase -Identity databasename -Status | Format-Table Name, DatabaseSize, AvailableNewMailboxSpace

 

Remove-StoreMailbox is the same command used for purging deleted mailboxes.

$mbxs = Get-MailboxStatistics -Database databasename_you_want_to_clean_up| where {$_.DisconnectReason -eq “Disabled”}

and then

$mbxs | foreach {Remove-StoreMailbox -Database $_.database -Identity $_.mailboxguid -MailboxState Disabled -Confirm:$false}

After you purged disabled or softdeleted mailboxes you should have created some whitespace for mailboxes to grow in without growing the EDB file.

Happy purging.

Update Calendar folder permission

Most admins have one time or another come across the need for changing permission on individual folders in mailboxes.
Most common cases I have seen this is for calendar folder in resource mailboxes.
This is an easy task but some challenges exist. To start with you use the MailboxFolderPermission cmdlet to set/add/remove permissions.

To read the existing permission on the calendar folder, run.

Get-MailboxFolderPermission -Identity LasseP

And you will see the following output.

FolderName : Top of Information Store
User : Default
AccessRights : {None}
Identity : Default
IsValid : True

FolderName : Top of Information Store
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

You see the usual Anonymous and Default permission group. Interesting here is that you see the permission for “Top of Information Store” which is the root folder in the mailbox.


To get permission for a specific folder you have to specify this as a parameter and here we must know the exact folder name. This gives us some interesting challenges for Multilanguage organization because the calendar folder can have different names.
So if I specify the calendar folder name in Swedish

Get-MailboxFolderPermission -Identity LasseP:\Kalender

I get an error because the folder name is not “Kalender”, but when specifying the English name I get what I want.

Get-MailboxFolderPermission -Identity LasseP:\Calendar

FolderName : Calendar
User : Default
AccessRights : {AvailabilityOnly}
Identity : Default
IsValid : True

FolderName : Calendar
User : Anonymous
AccessRights : {None}
Identity : Anonymous
IsValid : True

Folder name must also be correct when using Set/Add-MailboxFolderPermission.
So how do we know the calendar folder name for a mailbox?
Here is neat trick we can use to get the name with Get- MailboxFolderStatistics cmdlet.

Get-MailboxFolderStatistics -Identity LasseP -FolderScope Calendar | Select-Object -First 1).Name

The output will be a text string with the calendar folder name, in our example it is “Calendar”.
Selecting only the first object is needed because users can have more than a single calendar folder and we want only the default calendar folder in the mailbox which is returned first.
Next step is to update the ACL with new permission, and here we have one more challenge. We need to figure out if we want to add permission or change existing reason for this is that we have two cmdlet to use, Add-MailboxFodlerPermission and Set- MailboxFodlerPermission. Each one of them will give an error if used in the wrong context.

To add a new user (or a group) to the ACL, run.

Add-MailboxFolderPermission -Identity LasseP:\Calendar -User Eva -AccessRights Reviewer

This will grant user Eva the reviewer permission on LasseP’s calendar folder.
Running the same cmdlet again will give you an error with “Add-MailboxFolderPermission : An existing permission entry was found for user: Eva”.

To change the permission you must use Set-MailboxFolderPermission

Set-MailboxFolderPermission -Identity LasseP:\Calendar -User Eva -AccessRights Owner

The vice versa is true if you run Set-MailboxFolderPermission and the user being granted permission is not in the ACL you will get an error saying “Set-MailboxFolderPermission : There is no existing permission entry found for user: Axel”
So before we can update the folder permission you must know if the user/group is already member of the ACL. This is accomplished by using Get-MailboxFolderPermission, this we already tried earlier.
To make things easier without issuing multiple commands I created a script.

Update-CalendarFolderPermission.ps1

########################################
# Update-CalendarPermission.ps1 -Identify <mailbox> -User <xxx> -Permission <permission>

param
(
    [Parameter(Mandatory = $true, HelpMessage="Enter a mailbox where you apply permission to")]
    [ValidateNotNullOrEmpty()]
    [string]$Identity ,

    [Parameter(Mandatory = $true, HelpMessage="Enter a user/group who will be granted the permission  syntax domain\xxx might be needed")]
    [ValidateNotNullOrEmpty()]
    [string]$User = "",
    
    [parameter(Mandatory = $true, HelpMessage="Enter a valid permission set")]
    [ValidateSet("ReadItems","CreateItems","EditOwnedItems","DeleteOwnedItems","EditAllItems","DeleteAllItems","CreateSubfolders","FolderOwner","FolderContact","FolderVisible","None","Owner","PublishingEditor","Editor","PublishingAuthor","Author","NonEditingAuthor","Reviewer","Contributor","AvailabilityOnly","LimitedDetails","Remove")]
    [string]$Permission = ""
)

#Add Exchange 2010 Management Shell if needed
if (! (Get-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:SilentlyContinue) )    {
    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010 -ErrorAction:Stop
}

$MBX = Get-Mailbox $identity

$CalendarName = (Get-MailboxFolderStatistics -Identity $MBX.alias -FolderScope Calendar | Select-Object -First 1).Name
$folderID = $MBX.alias + ':\' + $CalendarName

if ($Permission -eq 'remove') {
    # special case, remove permission from user
    Remove-MailboxFolderPermission -Identity $folderID -User $User -Confirm:$False
}
else {
    $i = @(Get-MailboxFolderPermission -Identity $folderID -User $User -ErrorAction SilentlyContinue).count
    if ($i -eq 0) {
        # not in ACL, add permission
        Add-MailboxFolderPermission -Identity $folderID -User $User -AccessRights $Permission > $Null
    }
    else {
        # user is already in ACL, change permission
        Set-MailboxFolderPermission -Identity $folderID -User $User -AccessRights $Permission
    }

    # display new permission for $user
    Get-MailboxFolderPermission -Identity $folderID -User $User
}

Script isn't that hard to follow, there is some required input parameters needed. When this is handled, script continue with figuring out the calendar folder name then add or set permission depending on if user is already on ACL.

I also built in a special case where you could set permission to "remove" to remove the user from ACL on the calendar folder.


An example would be.

Update-Calendarpermission -identity Eva -User Lassep -Permission ReadItems

This will grant Lassep Read permission on Eva's calendar folder.


Script don't accept pipelining from other commands so if you want to update permission on multiple mailboxes you need to do this with two lines of code instead.

$mbx = Get-Mailbox conf*
foreach($mb in $mbx) { .\update-calendarpermission.ps1 -Identity $mb.Alias -User Lassep -Permission ReadItems}

First line is save mailboxes you want to change permission on into the $mbx variable.

Second line calls the Update-CalendarPermission script once for each mailbox in the $mbx variable.

The two line script will grant LasseP Read Permission on all 'conf*' mailboxes


now, go and play with this is a lab before running it on every mailbox in your production environment.

Using SuspendWhenReady

I recently did a migration from Exchange 2007 to Exchange 2010. We staged every mailbox move to use the SuspendWhenReady parameter on the New-MoveRequest to ensure that when we finally resumed the paused mailbox move everything should go as fast as possible.

Everything went OK, mailboxes started to move and when they reach 95% the suspended themselves. We did this for all approx. 5000 mailboxes and after a few days everything had been synchronized.

When time struck "migration" we started of by resuming about 100 mailboxes to see how the system responded. Whoa did we get a surprise, everything on the old Exchange 2007 server come to an almost complete freeze, it was almost unusable. We had some concerns with the old server since it was overloaded even before we started move mailboxes but we never thought it would be this bad.

Some hours of investigation and troubleshooting we discovered that when we kick of several hundreds of suspended mailbox moves the old server freeze but when we did 5 to 10 at a time everything worked as it should and with reasonable speed.

We didn't want to spend 24 hours manually resume 10 suspended mailbox moves every minute so I created a short EMS script that did it for us.

While ($True)
{
    Get-Date
    $nr = (Get-MoveRequest -ResultSize unlimited -MoveStatus InProgress).Count
    "moverequests " + $nr
    if ($nr -lt 2)
    {
        Get-MoveRequest -MoveStatus AutoSuspended | Select -First 10 | Resume-MoveRequest 
    }
    Sleep 60
    "-"
}

script runs in an endless loop, printing date and time to EMS window, calculate how many ongoing move-requests we have and when it is below 2 we fire of and resume 10 more. Finally a pause for 1 minute and do it all over again.

You might need to tweak this a bit by changing timeout and number of move requests to resume. In my case values in script worked fine but if you have an Exchange 2007 server that is not as squeezed then you might be fine with other values.

Find updates for Lync

Look at Updates Resource Center for Lync.

It contains link to updates for Lync server and for all different kinds of Lync clients.