Exchange 2010 Outlook Wep App (OWA) Changing the Default Spelling Dictionary

It Seems that in Exchange 2010 RTM & SP1 Outlook Web App (OWA). That the default Dictionary Reverts to English United States, Regardless of the CAS Server Language, Client Browser Language etc.

So, How do we change this for multiple or all users users ?
Answer
======
Using Powershell and MailboxSpellingConfiguration Applet command:

1. First lets check the current Dictionary setting for a Particular user,
    we will use:
 Get-MailboxSpellingConfiguration -identity usernamehere

This will present the following output. as can be seen, We have the wrong Dictionary..!

RunspaceId         : 9e7c7fdb-137d-45ac-b04b-71f74eb2e643
CheckBeforeSend    : False
DictionaryLanguage : EnglishUnitedSates
IgnoreUppercase    : False
IgnoreMixedDigits  : False
Identity           :
IsValid            : True

2. Now lets go about setting the Dictionary to our preferred Dictionary.
   So for ALL users the following command will be sufficient.

Get-Mailbox | set-MailboxSpellingConfiguration -DictionaryLanguage EnglishUnitedKingdom

 for a single user we would simply run:
set-MailboxSpellingConfiguration -identity username -DictionaryLanguage EnglishUnitedKingdom


 Running the Above PS Command will confirm the change on a user
Get-MailboxSpellingConfiguration -identity usernamehere
RunspaceId         : 9e7c7fdb-137d-45ac-b04b-71f74eb2e643
CheckBeforeSend    : False
DictionaryLanguage : EnglishUnitedKingdom
IgnoreUppercase    : False
IgnoreMixedDigits  : False
Identity           :
IsValid            : True

Want an Exchange 2007 OAB Generation Server, that only hosts Public Folder Database? Well you can't & will get errors, 8197, 9386 & 9399 thrown at you...

Scenario:

Brand new Exchange 2007 SP3 UR1 deployment in single windows 2003 Forest / Domain, single AD site spanning well-connected WAN.  Exchange is deployed on Windows Server 2003 x64.  4 x CAS / HT Servers, 2 x Public Folder Mailbox Servers (No Mailbox Stores Present), 2 x Mailbox Server roles (No Public Folder Stores Present, will act as Staging Servers for Quest EMW) and two x CCR clusters (one node in each site, but these aren't relevant yet for this issue).

Added replicas of system Public Folders from PF server 1 to PF Server 2.
Added single Mailbox database to Mailbox-Only Staging server 1, and set Default Public Folder store to point to Public Folder Server 1.

Problem being experienced:

This issue came to light, when we hooked up an Outlook 2003 client to a test mailbox located on the Staging server, and got an 'Error Downloading Address Book' error from Outlook…  'Contact your Administrator'.

Issues observed in Server Event Logs:

The error being logged every 25 minutes on the mailbox-only Staging server, where the test mailbox resided, was:

So, first thing was to try forcing an 'Update Now' on the OAB Generation Server (Public Folder Mailbox Server in this scenario), and then check 'Application' event log.  The command completes without reported error, but when checking the event log, the following are logged:
 

  

Now, the 'Web-Based' distribution part of this appears to be working just fine after forcing the OAB Generation Process for the first time.  Looking on the CAS Server, we can see that after an initial Warning that there are no files to collect, following the forced update, we now get this:

  

So, for E2K7 and above Outlook clients, this shouldn't be an issue.  But when we have the following boxes checked:

then we get the 9386 and 9399 errors being logged on the OAB Generation Server.

Testing things out, general Public Folder creation and replication between nodes is working just fine.  So clearly, the public folder stores are alive and present, contrary to the 9386 and 9399 events, happily accessible by Outlook 2003.  So why are the warnings stating that the PF database is not present?  My suspicion was perhaps you might need a System Attendant Mailbox present to perform certain System Attendant functions such as this, but I could not find anything concrete to support this theory initially, so tried various things to no avail in the first instance.

After reviewing this however:  http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/c58b47a7-4794-4486-81fc-28b9fbd10804/

right at the bottom of the thread, was something pointing towards what I had suspected earlier.

Situation 4, of the following MS article also points towards this:  http://technet.microsoft.com/en-us/library/bb331959(EXCHG.80).aspx

So, checking ADSIEDIT for the System Attendant HOMEMDB value on the Public Folder server showed that there was indeed no value specified, as expected.

To support this theory further, the following can be referenced:

http://social.technet.microsoft.com/Forums/en/exchangesvradmin/thread/9f762036-5486-4891-8af9-f27812ab49a7

So, I created a new SG and Mailbox DB on the Public Folder server.  Initially, you may not be able to mount the new DB after creating it, down to good old replication latency as usual.  Wait a minute or so, and as always with Exchange, the manual mount works just fine after that.

Here is the resultant event log sequence:

  

So, the first sets of red are moaning about not being able to locate the SA mailbox.

This goes away after a minute, as indicated in one of the warning events.  So we should now have an SA Mailbox:

And we do, with 402 items in it as per any other mailbox server doing very little.

Now, checking back in ADSIEDIT for the HOMEMDB attribute on the System Attendant for the PF server in question shows that we now have an attribute present.  All good!

OK, so try forcing OAB Generation again now, and check the event log out:

and there are now no 9386 or 9399 events reported, whereas before, this would be flagged pretty much instantly when the process failed.

So, things are hopefully happy now.

Checking back in the Public Folder Management Console, we will hopefully see some sub-folders of OAB being created, however you do get some latency experienced here, taking a few minutes for this to show up after the forced generation.  Closing and re-opening the PF Management Console reveals that these have now been created as desired, and we now have the OAB Version 2, 3a and 4 folders.

In addition, this has also solved the MSExchangeBPublish errors that were occurring on the Staging Mailbox Servers, that didn't have public folder stores, but that were pointing to the PF server above.  Note that these stop re-occurring at around 5pm, after reoccurring every 25 minutes before:

Conclusion:

So, if your aim is to have Mailbox role servers dedicated to hosting Public Folder databases and you also wish to make one of these an OAB generation server for legacy Outlook clients, then you MUST retain a local mailbox database also in order for the System Attendant Mailbox to do its job.  If you don’t, the only thing you get told about is that you don't have a Public Folder store alive or mounted and you could well spend a while trying to work out why.

Happy Generating!!

Manage domain member Hyper-V servers from a workgroup PC

A scenario that often arises when installing Hyper-V hosts (running Hyper-V server or server core) for a customer without any existing server 2008/R2 servers in their environment is the need to run the Hyper-V management console from somewhere (anywhere really) while you set the servers up...

There are some fairly extensive blog articles about this, but I have boiled the essentials down to a single, pithy screenshot as usual, also worth noting that this process assumes that you have enabled the remote management options (1, 2 and 3) using sconfig previously, and accepted the kind offer of a reboot afterwards:

Start your dcomcnfg console, browse to ‘My Computer’, click ‘Edit Limits’, and finally permit remote access for anonymous users.  To finish off you need half-an-hour at gas mark four, and some domain credentials added to your machine store for accessing the servers, (this can be done either using the cmdkey utility as shown here, or ‘Credential Manager’ in control panel if you must use a GUI, the account added must have local admin rights on the Hyper-V host) and you are good to go.  It might be worth noting here that there is an (unsupported but otherwise perfectly formed) utility called HVremote which has been released which can do all this for you, it’s just that personally I like to roll my own for stuff like this.  Also worth adding as a ‘Disclaimer’: anonymous remote access to your COM objects is a ‘Very Bad Thing’^TM and this should only be used as a temporary stopgap, un-set this when you are done.  Stay safe everyone.