Simply set the preferred language on the target mailbox. The following command will set the language, date format, time format and time zone to german language.
[ For OnPremise leave the -Organization or -OrganizationalUnit switch away. More on syntax: MutliTenant VS. OnPremise ]

The default parameters for english / US are:

-language : en-US
-dateformat : M/d/yyyy or MM/dd/yyyy
-timeformat : h:mm tt or HH:mm
-timezone : “Pacific Standard Time”

The LocalizeDefaultFolderName switch turns the default folders to the set language. If you set it to $false the default folders will not switch to the new language.

The mailbox import request language settings shouldn’t be a problem now. Trigger the import of the .pst using the following CMDlet :

If the import request fails you can play with the following parameters :

-BadItemLimit : Specifies the amount of corrupted items to be ignored without failing the import request.
-AcceptLargeDataLoss : Needed if you set the BadItemLimit above 50.
-LargeItemLimit : Specifies the amount of large items to be ignored without failing the import request.
[ LargeItemLimit is not available in Exchange 2010]

The post Mailbox Import Request language settings appeared first on Webbanshee.

Removing ( if still there ) the move-requests does not help, even not through ADSIedit.

You think propably moving these mailboxes to another mailbox database again would solve the problem. But you cannot trigger a new move-request for these mailboxes since you receive warnings like this :

The solution is to start the move-request as follows :

-MRSServer :
There will be no switching between CAS servers when peforming the move-request. The move request will completly handeled by the given CAS server.

-DonNotPreserveMailboxSignature : This one is the real solution. Where MailboxSignature is not the lokal Outlook signature you use at the end of an email. This parameter is responsible ( Exchange 2010 ) for the fact , that the user will not notice the mailbox move. Otherwhise the users needs to close Outlook and reconnect. ( This is what will happen when you use the move-request above )

We noticed this behaviour after we have rolled up to 2010 SP3 RU14 .

The post Your mailbox is being moved – Exchange 2010 appeared first on Webbanshee.

A user makes a new meeting request and sends it to a resource mailbox. The meeting will be placed  in the calendar of the user and in the calendar of the resource mailbox. The status in the resource calendar stays tentative.  Some minutes later the same user wants to delete the meeting ( for whatever reason ).

Because he is not the delegate / owner of the resource mailbox he just can cancel the meeting in his own calendar. The result is that the canceled meeting stays in the resource calendar just labeled :  canceled.

This comes because the AutomateProcessing Parameter within the Get-CalendarProcessing CMDlet is set to AutoUpdate. AutoUpdate places the meeting in the calendar of the resource mailbox and updates it to tentative. On the other hand the cancel request will not be processed with AutoUpdate, instead just the owner of the resource mailbox can remove these canceled meeting requests from the calendar.

To remove canceled meeting requests from the resource mailbox calendar we need to modify the AutomateProcessing parameter :

Setting the AutomateProcessing parameter to AutoAccept will place the meeting requests as accepted meetings in the calendar and will process the cancelation requests for meetings directly , without any intervention of the owner. This keeps the resource calendar clean and transparent.

First we need to know the values of following CalendarProcessing Parameters :

To allow users to remove canceled meeting requests these parameters should have the following values :

The values can be adjusted as follows :

To use it in a 2010 MultiTenant environment replace -OrganizationalUnit with -Organization.
To use it on an OnPremise server just leave -OrganizationalUnit or Organization away.

Your users will now be able to remove canceled meeting requests from a resource calendar.

The post Remove canceled meeting resource calendar appeared first on Webbanshee.

However, to solve this issue on client side,  the external recipients having this problem, should be present in your Contacts folder.

It does not help to specify in the settings to send Emails in HTML format. You need to force it on the recipients.

See a server side solution here :

Winmail.dat Attachment Exchange

The post Winmail.dat Attachment Outlook appeared first on Webbanshee.

To solve the winmail.dat issue on serverside the external recipients should be added as Mail-Contacts to the Exchange organization. You can force Exchange to never use RichTextFormat when sending mails to these Mail-Contacts.

To force Exchange to never use RTF format when sending to external contacts use :

Exchange 2010 Multi-Tenant : ( for a certain Mail-Contact ) 

Exchange 2010 Multi-Tenant : ( for all Mail-Contacts in an organization )

Exchange 2013 / 2016 Multi-Tenant : ( for a certain Mail-Contact )

Exchange 2013 / 2016 Multi-Tenant : ( for all Mail-Contacts in an organization )

For Exchange OnPremise you should most likely use these CMDlets without the -Organization or -OrganizationalUnit switch.

You can also consider to use the Remote Domain solution.

Since we only have Multi-Tenant environments we want to control this on organization level. For this reason we did not mess with the Remote Domain.  Hence we have not tested it. But a comment on this from someone , who has implemented the Remote Domain solution in a Multi-Tenant environment , would be well appreciated.

This will solve the problem on serverside. Attachments will not longer appear as winmail.dat files.

See a client side solution here :

Winmail.dat Attachment Outlook

The post Winmail.dat Attachment Exchange appeared first on Webbanshee.

This can be achieved through a Throttling Policy where you set the Recipient Rate Limit to a value which fits your customers mail sending practices, but prevents a spam critical amount of outbound mails.

In this example we will set the value to 2000 mails / 24 hours :

Apply the Recipient Rate Limit Exchange Server wide on all mailboxes : ( Exchange 2013 / 2016 )

Apply the Recipient Rate Limit for a certain organization : ( Hosted Exchange 2010 Multi-Tenant)

Apply it on an Exchange 2010 OnPremise :

Remember not to alter the Default Throttling Policy since this is the template for all further Throttling Policies you create.

To apply a Throttling Policy on mailbox level please see the following post :

New Throttling Policy Exchange 2013 / 2016

The post Recipient Rate Limit Throttling Policy Exchange appeared first on Webbanshee.

This is caused by when Outlook tries several variants of autodiscover requests when establishing a connection. This can be solved by excluding time-consuming autodiscover lookups on client side.

The following 2 registry keys can be implemented to get around this behaviour :

Setting this key solved all issues we had users experiencing a delayed calendar content display in Outlook.

Please make sure to use the appropriate path for your Office version when navigating through the registry.

Office Versions :
2010 = 14.0
2013 = 15.0
2016 = 16.0

When setting up a new profile in Outlook and autodiscover takes ages please take a look at :

Outlook autodiscover takes a very long time

The post Delayed calendar content display Outlook appeared first on Webbanshee.

This can be solved by implementing the following 2 registry keys on the PC running the Outlook client. ( Outlook should be closed )

Please choose the appropriate Office version when navigating down the registry path. ( this example is for Office 2013 = 15.0 ) :

Office Versions :
2010 = 14.0
2013 = 15.0
2016 = 16.0

The annoyance that autodiscover takes long time will be gone with these registry entries.

The post Autodiscover takes long time Outlook appeared first on Webbanshee.