Removing managed mailboxes from an Outlook profile

Following a server migration, an administrator had user’s mailboxes showing up in his profile. This was the result of giving himself Full Access permission to the mailboxes during the migration.

When a user has Full Access permission to another user’s mailbox, Outlook 2007 and above automatically opens the mailbox in the profile. (The mailboxes were not listed as secondary mailboxes in Account Settings.)

The administrator removed Full Access permission for the mailboxes but this didn’t remove the accounts from his profile.

Following an Exchange server upgrade, I have several users mailboxes in my profile. I cannot close the mailboxes. The accounts are not listed as additional mailboxes in my profile. I removed Full Access permissions. Any idea of how to get rid of these extra mailboxes?

Edit the user account in ADUCYou need to edit the user accounts in the Active Directory and remove your name from theMsExchDelegateListLink attribute.

  1. Open Active Directory Users and Computers
  2. Go to View menu and select Advanced Features
  3. Open the user account that is showing in your mailbox (in the screenshot, my mailbox is in Mary’s profile)
  4. Open the Properties dialog
  5. Click Attribute Editor tab
  6. Locate MsExchDelegateListLink
  7. Click Edit
  8. Remove your name from the attribute
  9. Close the dialogs

Keep FullAccess Mailboxes from being AutoMapped

Not everyone likes automapping of mailboxes, It’s great for the end-user: the mailboxes they have permission to open are automatically added to their profile, avoiding the need to go into the profile and add the secondary mailbox manually. But not everyone wants to see the shared mailbox in their profile.

It’s possible to give a user full access to a mailbox without automapping by adding –AutoMapping $False parameter to the Add-MailboxPermission cmdlet.

 

Add-MailboxPermission "shared-mailbox" -User "alias" -AccessRightsFullAccess –AutoMapping $False

Exclude DC from DSAccess of Exchange Server

By default, DSAccess or ADAccess chooses the primary domain controller (PDC) emulator operations master role computer to handle requests in Microsoft Exchange. This action may result in poor performance if other non-Exchange programs are making heavy use of the PDC emulator.

To resolve this issue, use one of the following methods, as appropriate for your situation.

Method 1: Microsoft Exchange 2000 Server and later versions

To resolve this problem in Exchange 2000 Server and later versions, add the MinUserDC registry value to exclude the PDC emulator from the server list that Exchange can use.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

To add the MinUserDC registry value, follow these steps:

  1. Start Registry Editor.
  2. Locate and then click the following subkey in the registry:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

    Note In Exchange Server 2007 and in Exchange Server 2010, locate the MSExchangeADAccess subkey instead of the MSExchangeDSAccess subkey.

  3. On the Edit menu, click Add Value, and then add the following registry value:
    Value name: MinUserDC
    Data type: REG_DWORD
    Value data: As required

    Note The MinUserDC entry determines how many total user domain controllers must be available for PDC emulator exclusion to turn on. The value data that is configured for the MinUserDC registry entry is the maximum number of domain controllers to contact before the PDC emulator is contacted. For example, when you set MinUserDC to 4, this configures DSAccess to exclude the PDC emulator only when a total of four domain controllers are available. When this condition is met, the PDC emulator is excluded from use, and DSAccess communicates only with the remaining three domain controllers.

  4. Exit Registry Editor.

Notes

  • You have to apply the registry change that this article describes regardless of the service pack that is installed.
  • In Exchange Server Enterprise Edition, the Profiles subkey and the Default subkey are not available. You must create these subkeys in Exchange Server Enterprise Edition.
  • When you determine a value for MinUserDC, consider the equation n – 1, where n is equal to the total number of domain controllers in the site. This number includes the PDC emulator. Subtract 1 from this number, and the sum should be the value that you enter for MinUserDC.

Method 2: Exchange Server 2007 and Exchange Server 2010

In Exchange Server 2007 and in Exchange Server 2010, you can use a cmdlet to configure the ADAccess component to exclude a particular domain controller or a list of domain controllers from use. To do this, use the Set-ExchangeServer command together with the StaticExcludedDomainControllers option.

The following example shows how to use the Set-ExchangeServer command to exclude one or more domain controllers from use. Additionally, this example shows how to verify the status of the Exchange environment after you run the Set-ExchangeServer command.

In this example, you have the following servers:

Host name Domain Role
E2K7-1 contoso.com Exchange Server 2007
DC-1 contoso.com domain controller together with PDC operations master
DC-2 contoso.com domain controller
DC-3 contoso.com domain controller

To use the Set-ExchangeServer command to exclude the three domain controllers that are listed in this table from use for the DSAccess component, follow these steps:

  1. Start the Exchange Management Shell. To do this, click Start, point to All Programs, point to Microsoft Exchange Server 2007, and then click Exchange Management Shell.
  2. At the command prompt, type the following command, and then press Enter:
    Set-ExchangeServer -identity E2K7-1.contoso.com -StaticExcludedDomainControllers:dc-1.contoso.com,dc-2.contoso.com,dc-3.contoso.com

    This command excludes DC-1, DC-2, and DC-2 from use by the server that is named E2K7-1.

    Note In this command, specify the fully qualified domain names of the individual domain controllers by using a comma-separated list that does not contain spaces between each entry.

  3. To verify the list of excluded domain controllers, type the following command, and then press Enter:
    Get-ExchangeServer -identity E2K7-1.contoso.com -status | fl Name, StaticExcludedDomainControllers

Note If you want to remove the changes that you have made and revert to the default behavior of Exchange, type the following command at the Exchange Management Shell prompt, and then press Enter:

Set-ExchangeServer -identity E2K7-1.contoso.com -StaticExcludedDomainControllers:$null

 

6 ways to enable SSH on an ESXi host

Option 1: enable Remote Tech Support (SSH) via the DCUI

Enabling Remote Tech Support (SSH) is ideal production systems, because you can enable it and leave it turned on for an x amount of time, and after the time out SSH is being disabled automatically, so the system is secure again. One small drawback is that you need to have either a physical console access or a iLO, DRAC or some other remote console access.

If you’re running vSphere 4.1 you can also enable this via the vSphere Client, see option two for more details.

Once you have direct console access to the DCUI of the ESXi server you’re able to enable Remote Tech Support (SSH) on the ESXi host, but first you need to login with the right credentials, in most cases this will be the root account.

You will find the Remote Tech Support option under the Troubleshooting Options.

Select Enable Remote Tech Support (SSH) to enable the SSH service, be patient because it will take some time to enable it, if you press Enter twice you will disable Remote Tech Support :-) .

After a few second Remote Tech Support should be enabled, if not press the Enter key one more time until you see a screen as shown above. Sometimes it can be hard to enable it through the DCUI especially when using iLO, but maybe that’s because I’m not patient enough :-).

To enable a timeout on which the SSH service is turned on, select Modify Tech Support Timeout, and hit Enter to continue, this option is not required, it can be useful to provide someone access to the ESXi host for just a few minutes/hours. I recommend you to always set this time out on production systems, because you can’t forget to turn if off again.

Enter any value between 0 (zero) and (one day) 1440 minutes (where zero is to disable it, and 1440 is the maximum) to enable the SSH  time out, press Enter to activate it.

To test if it’s working, you can use Putty to connect to the ESXi host.

Once you’re enabled the Remote Tech Support feature you will receive a message within the vSphere Client (both if your directly connected to a ESXi host or through the vCenter Server) indicating that Remote Tech Support Mode is enabled. Personally I like this notification, because it will remind you that SSH is still enabled, so you can’t forget to turn it off :-) .

When the timeout expires, you see it is not possible to create a new SSH session to the ESXi hosts (Note: only if you’re entered an timeout value in the Timeout for Tech Support Mode Text, or if you manually disable it). However this timeout does not apply for connections that are still active, so it’s still possible that someone still have access to the ESXi host even while Remote Tech Support is already disabled, so keep that in mind.

Option 2: enable Remote Tech Support (SSH) via the vSphere Client

As mentioned before, with the introduction of vSphere 4.1 you will be able to enable the Remote Tech Support through the vSphere Client, either directly connected to the ESXi host or through the vCenter Server. Bellow I will only describe how to enable it if you’re connected through the vCenter Server. If your doing this by connecting the vSphere Client directly to the ESXi hosts, you can also use these steps because it’s not that different.

If you’re using vSphere 4.1, I recommend using this way to enable SSH for a production ESXi host, because it’s easy to do and it can be done without the need of a direct console connection.

The first step off cource is to open the vSphere Client and logon to you’re vCenter Server, if your not already done that:-).

Once you logged in, select the ESXi host on which you want to enable SSH, and click on theConfiguration tab, in the Software screen click on Security Profile. In the Services field click on Properties.

Select the service: Remote Tech Support (SSH) and click on Options.

Click on Start to enable the Remote Tech Support (SSH) service, you can leave the Start-up Policy as it is.

Verify that the Remote Tech Support (SSH) service is running and click on OK.

Once you have enabled the Remote Tech Support Mode you will receive a message on the ESXi host, that the service is enabled.

One (small) drawback of this method is, that it isn’t possible to use a timeout on the SSH service directly within the Services screen, to enable the timeout you need to go toSoftware/Advanced Settings.

Select: UserVars and enter the required timeout value in the UserVars.TSMTimeOut (note: the timeout is in seconds, in my example I have configured a timeout of 30 minutes –> 1800 seconds) click on OK to enable the timeout feature.

Option 3: enable the SSH service through the Busybox

This is a more old school way of turning on the SSH service, if I remembercorrectly this procedure is still more or less the same since VMware ESXi 3, but correct me if I’m wrong here.

Unfortunately to get this working you need to have a direct console access or via iLO, DRAC to open the console on the ESXi host.

One other (big) drawback is that you won’t know if the SSH service is enabled or not, unlike the two other ways there’s no warning message in vCenter that will let you know if SSH is enabled, so in my opinion this is not a great way to turn on SSH on production ESXi hosts, but could be useful for example in Labs where you want to have quick access to the ESXi host.

Once you have access to the console, press ALT + F1 to access the console (Busybox), and login with the root credentials.

If you receive a message like the one above here, you need to enable Local Tech Support, standard this is turned off so you need to turn it on before you can access the console of the Busybox.

Press ALT + F2 to get back to the ESXi DCUI console (the yellow-grey screen) and login and select Troubleshooting Options.

Select in the menu Enable Local Tech Support and hit Enter to enable this function, this could take some time before the service is enabled, so be patient otherwise you disable the function:-) .

Now you have enabled Local Tech Support, lets get back to the console of the Busybox by pressing ALT + F1 keys.

Login with the root account.

Edit the inetd.conf file located in /etc/inetd.conf, in this example I use the VI editor.

Once the file is opened in the VI editor, press the Insert key to edit the inetd.conf file.

Depending on if you’re use IPv4 or IPv6 you need to edit the correct line, for IPv4 you need to edit the #ssh line and remove the # to enable the ssh service in the configuration file. Press on Esc and exit with the command :wq.

The SSH service will only start until the inetd reads it’s changed configuration file, this can be done by rebooting the ESXi host, or even better by restarting the inetd process. To do so we first need to have the process id of inetd, this can be done by execute the following command;ps | grep inetd you will receive a number which is the process id of inetd, in my case the process id is 4860.

To kill the inetd process, execute the command; kill -hup 4860 (where 4860 is the process id of inetd).

If everything is working fine you should be able to access the ESXi host via SSH, like in the example above I accessed the ESXi host via Putty and I’m able to login with the root account. Don’t forget to disable it once your work has been done :-) .

Option 4: Enable SSH through PowerCLI

Big thanks to Alan Renouf over at virtu-al.net and Arne Fokkema over at ict-freak.nl for pointing me at a great blog post written by Alan Renouf himself. As Alan mentioned in his blog, it is possible to enable ESXi hosts services via the PowerCLI, here’s how you can do it.

You can show the running services by execute the command: Get-VMHostService as shown here above.

To enable it you can execute this line of code:

Get-VMHost | Foreach { Start-VMHostService -HostService ($_ | Get-VMHostService | Where { $_.Key -eq “TSM-SSH”} ) }

As you can see here above the service is now started.

Option 5: Enable SSH with help of a Perl script

Also a big thanks to William Lam over at VirtuallyGhetto.com, he has written a very cool perl script to enable services, on one or multiple ESXi hosts which can be run from the vSphere CLI or the vMA.

As mentioned here above this script can be run from the vMA or the vSphere CLI, in this example I run it locally from my notebook through the vSphere CLI, but it works the same on the vMA.

Start the vSphere CLI and browse to the folder which contains the hostServiceManagement.pl script (the script can be found here) and execute the following command to get a over view of the services:

hostServiceManagement.pl –server [hostname] –operation query

To enable the Remote Tech Support (SSH) service we need to use the TSM-SSH service, which is not running at the moment.

To enable the Remote Tech Support service you need to execute the following command:

hostServiceManagement.pl –server [hostname] –operation start –service TSM-SH

Run the query command and you will see that the service is started correctly, I recommend you to read William’s blog post about this because you can also do this on multiple ESXi hosts, which can be very handy in large environments.

Option 6: Enable SSH within the kickstart script

William Lam also pointed me at a another way to turn on SSH during the installation, by adding a command line to the kickstart script.

This could be useful if you want to configure or check some items on the host just before you take it in production, but remember disable it once it’s running production load.

You just need to add the following two lines to the kickstart script:

vim-cmd hostsvc/enable_remote_tsm  (this will change the startup policy to “start and stop with the host”, if you don’t add this line and the host will reboot you won’t have SSH access anymore)

vim-cmd hostsvc/start_remote_tsm     (this will start the service)

One last note, I see an ESXi host more like an appliance, so I don’t want to have any unnecessary ports to be open on the host itself, because each open port is a potential security risk. That’s why I recommend not to enable SSH on a production ESXi hosts, just for security reasons. In a lab environment where security is not always a big issue you can enable SSH to get quick access to the host, or to check or test things out.

Personally I’m moving more and more over to the vMA (vsphere Management Assistant) which is a nice little appliance that’s capable of doing everything that you could do on the ESXi console and even more. The vMA is somewhat like a ”distributed” service console (dSC – Distributed Service Console, I wonder when VMware will use that term :-) ) from which, you can access any ESXi host and execute tons of commands just like your accessing an ESX(i) hosts.

Updating Client Access Servers to Exchange 2010 SP3

Microsoft has released Service Pack 3 for Exchange Server 2010. This is a significant release that delivers some key functionality to customers such as support for Windows Server 2012, support for co-existence with Exchange Server 2013 CU1, and general bug fixes and security updates.

If you are planning to upgrade your Exchange 2010 servers to SP3 you should be aware that there is an Active Directory schema update involved. If that is a concern for your environment, but you still want the bug fixes and security updates, you might consider sticking with Service Pack 2 and applying Update Rollup 6 instead.

At the time of this writing there are some points in the various release notes that aren’t correct or fully updated yet that Microsoft are still working on or that are worth some clarification:

  • Exchange 2010 SP3 is listed as including all security bug fixes up to SP2 UR5-v2. It actually includes all security and bug fixes up to SP2 UR6.
  • The SP3 release notes state you can only install on Windows Server 2008 SP2 or 2008 R2. You can actually install on Windows Server 2012, although exact pre-requisite guidance may not be available yet.
  • The support for Windows Server 2012 includes both the installation of SP3 on Server 2012, and the interoperability of Exchange 2010 SP3 with Server 2012 domain controllers.
  • The support for Windows Server 2012, which ships with PowerShell 3, does not mean that Exchange 2010 SP3 also supports upgrading to PowerShell 3 on other operating systems.
  • The co-existence support for Exchange 2013 does not apply to Exchange 2013 RTM, but rather Exchange 2013 CU1 (cumulative update 1) due for release in Q1 of 2013 (within about 6 weeks from the time of this writing)

Preparing to Upgrade to Exchange 2010 SP3

You can download Exchange 2010 Service Pack 3 here and extract the files ready to be installed on your servers.

Upgrade your servers in the following order:

  1. Client Access servers (beginning with the internet-facing site)
  2. Hub Transport and Edge Transport servers
  3. Mailbox servers
  4. Unified Messaging servers

You should also plan to update any management tools installations you have on admin workstations or servers, and also check your third party applications that integrate with Exchange in case they also need updated management tools.

I’m going to walk through the upgrade process in some more detail next, and also provide some general guidance afterwards about the Service Pack 3 installation steps as well as what to expect in terms of timing and service interruptions.

Applying the Schema Update

If you have an AD forest topology with multiple domains, or process restrictions that require schema updates to be managed a certain way, you can apply the Exchange 2010 SP3 schema update on a 64-bit domain controller that is in the same AD site as the Schema Master, using an account with Schema Admins and Enterprise Admins rights.

C:\Admin\Ex2010SP3>setup.exe /PrepareAD

Otherwise the schema update will be applied when you upgrade the first Exchange server.

Updating Client Access Servers to Exchange 2010 SP3

Client Access servers are the first server role to update, and you should begin with the internet-facing site if you have multiple sites in your organization.

For Client Access servers that are in a CAS Array you should remove some of the servers (eg half of them) from the load balancer configuration, upgrade them, re-add them to the load balancer, then repeat the process with the remaining Client Access servers in that load balanced array.

For an example of how to do this with Windows NLB see the following article:

For other load balancers refer to your vendor documentation for how to take servers out of the load balanced array for maintenance and updates.

Updating Mailbox Servers to Exchange 2010 SP3

I admit I was concerned when I read the release notes for Exchange 2010 SP3 that state:

The database schema has been updated in Exchange 2010 SP3. As a result, when Mailbox servers are upgraded to Exchange 2010 SP3, the databases are upgraded to the Exchange 2010 SP3 version of the database schema…

During the upgrade, the database is dismounted, and all mailboxes in that database are taken offline.

This seemed to be a major issue to me until I performed the upgrade in my test lab. The statement above is correct for standalone mailbox servers, which is expected.

However for an Exchange 2010 Database Availability Group the upgrade process can be performed with no downtime following the normal process of moving active databases off DAG members while they are being updated.

You can use the standard process as demonstrated here:

However, be aware that once a database has been made active on an Exchange 2010 SP3 member of the DAG, it can’t be made active on a pre-SP3 DAG member again. This means that you will need to roll through your entire DAG upgrading to Service Pack 3 to retain the full availability resilience your DAG is designed to provide.

Upgrading Other Server Roles to Exchange 2010 SP3

For Hub Transport, Edge Transport, and Unified Messaging servers there are no special steps required other than to manage your upgrades in a way that aligns with whatever high availability you have in place or those server roles. For example if you have two Hub Transport servers in a site, upgrade them one at a time.

Exchange 2010 Service Pack 3 Step by Step

The upgrades steps are very straightforward and easy to follow. Extract the SP3 files to a folder and run Setup.exe. When the splash dialog appears click Install Microsoft Exchange Server upgrade.

exchange-2010-sp3-install-01

You’ll need to click through the usual introduction and license agreement.

exchange-2010-sp3-install-02

exchange-2010-sp3-install-03

Next the Readiness Checks will be performed. Any errors will prevent you from proceeding. Warnings will not prevent you from proceeding, but you should pay attention to them anyway as they are often important.

Remember, if you’re upgrading CAS Array or DAG members refer to the guidance above.

Click Upgrade when you’re ready to proceed.

exchange-2010-sp3-install-04

The actual installation time will vary depending on the server roles installed, and whether you’re upgrading from a very recent or much older Service Pack level of Exchange.

exchange-2010-sp3-install-05

When the installation has all completed successfully click the Finish button.

exchange-2010-sp3-install-07

Each of my test lab servers took between 20 and 30 minutes to upgrade, but your performance will no doubt vary.

Exchange Server 2010 Build Numbers and Release Dates

To view the build number for the version of Exchange 2010 that you’re running, run the following command in the Exchange Management Shell:

Get-ExchangeServer | fl name,edition,admindisplayversion
noteNote:
After you install an update rollup for Exchange 2010, the version of Exchange Server isn’t updated to show that the update rollup is installed. This issue occurs because the version number that is displayed by the Exchange Management Console or by other administrative mechanisms is obtained from the Exchange Server Object in Active Directory.

For information about the servicing strategy for Exchange 2010, see Exchange 2010 Servicing. For more information about installing an update rollup for Exchange 2010, seeInstall the Latest Update Rollup for Exchange 2010.

Exchange Server 2010 SP3 build numbers

Product name Release date Build number
Microsoft Exchange Server 2010 Service Pack 3 (SP3) February 12, 2013 14.03.0123.004

Exchange Server 2010 SP2 build numbers

Product name Release date Build number
Update Rollup 6 for Microsoft Exchange Server 2010 Service Pack 2 (SP2) February 12, 2013 14.02.0342.003
Update Rollup 4 v2 for Exchange Server 2010 Service Pack 2 October 9, 2012 14.02.0318.004
Update Rollup 4 for Exchange Server 2010 Service Pack 2 August 13, 2012 14.02.0318.002
Update Rollup 3 for Exchange Server 2010 Service Pack 2 May 29, 2012 14.02.0309.002
Update Rollup 2 for Exchange Server 2010 SP2 April 16, 2012 14.02.0298.004
Update Rollup 1 for Exchange Server 2010 SP2 February 13, 2012 14.02.0283.003
Exchange Server 2010 SP2 December 4, 2011 14.2.247.5

Exchange Server 2010 SP1 build numbers

Product name Release date Build number
Update Rollup 7 v2 for Exchange Server 2010 SP1 October 10, 2012 14.01.0421.002
Update Rollup 7 for Exchange Server 2010 SP1 August 8, 2012 14.01.0421.000
Update Rollup 6 for Exchange Server 2010 SP1 October 27, 2011 14.01.0355.002
Update Rollup 5 for Exchange Server 2010 SP1 August 23, 2011 14.1.339.1
Update Rollup 4 for Exchange Server 2010 SP1 July 27, 2011 14.1.323.6
Update Rollup 3 for Exchange Server 2010 SP1 April 6, 2011 14.01.0289.007
Update Rollup 2 for Exchange Server 2010 SP1 December 9, 2010 14.01.0270.001
Update Rollup 1 for Exchange Server 2010 SP1 October 4, 2010 14.1.255.2
Exchange Server 2010 SP1 August 23, 2010 14.01.0218.015

Exchange Server 2010 RTM build numbers

Product name Release date Build number
Update Rollup 5 for Exchange Server 2010 December 13, 2010 14.0.726.0
Update Rollup 4 for Exchange Server 2010 June 10, 2010 14.0.702.1
Update Rollup 3 for Exchange Server 2010 April 13, 2010 14.0.694.0
Update Rollup 2 for Exchange Server 2010 March 4, 2010 14.0.689.0
Update Rollup 1 for Exchange Server 2010 December 9, 2009 14.0.682.1
Exchange Server 2010 November 9, 2009 14.00.0639.021

 

Connecting the Disconnected in Exchange 2010

In Exchange 2010 (2003 and 2007 as well) we have the option to “remove” the mailbox of a mailbox user (remove is quoted, because the action itself is called Disable). What really happens when you disable a mailbox is that the mailbox is disassociated from the related user object in Active Directory by removing the user object’s Exchange attributes. The mailbox is also said to be ‘orphaned’ because it has no associations with a user object. During the maintenance cycle, the mailbox will be marked for removal.

Mailbox Retention

After disabling a mailbox it will still be present in the mailbox store and it is marked for removal. During maintenance, the MSExchangeIS process will check for mailboxes marked for removal and which are past their retention period. The retention period is a configurable setting and by default it is set to 30 days, meaning you can recover deleted mailboxes within 30 days.

In order to configure the mailbox retention setting from the Exchange Management Console in Exchange 2010, navigate to Organization Configuration > Mailbox and then select the database in the Database Management tab. Select its Properties and configure the “Keep deleted mailboxes for (days)” setting on the Limits tab:

Now on to the fun part. For starters, we will have a user with a mailbox and without a personal archive, like in the pre-Exchange 2010 era. Nothing new here, from the Exchange Management Shell we can disable the mailbox by selecting it and selecting Disable.

Disable-Mailbox <UserID>

Do not make the mistake of using the Remove-Mailbox cmdlet, which is similar to the possible confusion in the Exchange Management Console as mentioned earlier. A useful addition to the Remove-Mailbox cmdlet when compared to the Remove action found in the Exchange Management Console is that you can use Remove-Mailbox in conjunction with the Permanent parameter to immediately remove the mailbox, without having to wait through the “Deleted Mailbox Retention” period. It is not possible to recover the mailbox once you have done this.

You can also use the Remove-Mailbox cmdlet to permanently remove disconnected mailboxes without needing to wait for the retention period to expire. To use this we need to specify the mailbox Database as well as the ExchangeGuid:

Remove-Mailbox –Database <DatabaseID> –StoreMailboxIdentity <ExchangeGuid>

Disconnected mailboxes appear in the Disconnected Mailbox view in Exchange Management Console (if the naming were consistent, this would be called Disabled Mailbox). We can right click on a disconnected mailbox, select Connect and choose a matching user or a different user to which to connect the mailbox. A matching user will be based on matching values in the LegacyExchangeDN or DisplayName properties. When selecting a different user the requirement is that the user must not already have a mailbox connected.

Note that disconnected mailboxes may not show up immediately because of delays caused by replication or if the status of the mailbox hasn’t been updated in the store yet. To scan Active Directory for disconnected mailboxes and update the status in the store accordingly, you can use the Clean-MailboxDatabase cmdlet, e.g.

Get-MailboxDatabase | Clean-MailboxDatabase

Perhaps unnecessary to say, but don’t select Remove to remove a mailbox. The Remove option will not only disconnect the mailbox but will also delete the associated user object. You will not be the first to accidentally remove the user object when you only intended to remove the mailbox selecting the Remove option. After all, you are in a Mailbox view so Remove implies removing a mailbox. The action Disable is also improper naming since it doesn’t disable the mailbox but marks the mailbox for deletion. After the retention period it will be deleted permanently. That’s not what “Disable” implies. After all, disabled user accounts are not deleted from the Active Directory after their tombstone expires.

To disable a mailbox from the Exchange Management Shell use the Disable-Mailbox:

Cleanup

Finally, if you want to clean up (i.e. purge) all disconnected mailboxes and archives in an organization and don’t want to wait for their retention period to expire, use the following cmdlets:

$disMbx= Get-MailboxDatabase | Get-MailboxStatistics | where { $_.DisconnectDate –ne $null }$disMbx | % { Remove-Mailbox –Database $mbx.DatabaseName –StoreMailboxIdentity $mbx.MailboxGuid}

The first operation retrieves all disconnected mailboxes in the organization and assigns the variable $disMbx to it. The second operation loops through all entries in $disMbx and removes them one by one (the percentage symbol is an alias for foreach-object). Needless to say, perform this action only after creating a proper backup of your Exchange environment.

Granting write permission for calendar sharing with OWA 2010

The calendar sharing feature introduced in Outlook Web App 2010 (OWA) allows a user to grant access to their calendar to another user.

To access the option, click on the Shareoption when in the Calendar and then on Share This Calendar. You’ll then be able to select the user(s) that you want to share your calendar with and define the level of information you want the recipient to be able to see in your calendar.

The recipients see a message as shown below. To access the calendar, they simply click on the Add This Calendar link. OWA will then add the calendar to the list of available calendars and the user can then access your calendar whenever they want by simply clicking on the calendar’s entry to instruct OWA to open it.

The user will be able to see your calendar but they won’t be able to add anything to it or make a change to an existing appointment. In short, they are restricted to “Reviewer” access. You can confirm this by clicking on the Change Sharing Permissionsoption in the Share menu, when you’ll see something like the screen shot shown below. In this case, just one other user has access to the calendar and all they have is Reviewer access, so it shouldn’t come as a surprise that they won’t be able to add or edit items in the calendar.
To set edit permission on Calendar

Set-MailboxFolderPermission -Identity alias:\Calendar -User UsertoGetRights -AccessRights Editor

For example, if my alias is “TRedmond” and I want to grant access to the user “Redmond, Eoin”, the command is:

Set-MailboxFolderPermission -Identity TRedmond:\Calendar -User ‘Redmond, Eoin’ -AccessRights Editor

How OWA displays a user with Editor permission

Once a user has been granted Editor permission, they can edit or add items to a calendar. Note the “Notify” checkbox. If set, the user who owns the calendar will receive an “Appointment Created Notification” as a new message in their inbox to provide them with details of the new event.

Creating a new appointment in another user’s calendar

Calendaring sharing is a nice feature of OWA 2010. It’s just a pity that the developers left out the ability to grant editor access to a calendar – but now you know how to do it behind the scenes!