Monday, September 08, 2008

Setting the OWA themeid via a script in Exchange 2007

This is a workaround for lack of the ability to set the OWA themeid programatically for those interested in the Technical side this setting is held in a FAI Message with a message class of "IPM.Configuration.OWA.UserOptions" in the Non_IPM_subtree of a mailbox. The setting is held as part of XML string in the 0x7C070102 binary mapi property on this item. Because there is no documentation for the structure of this property it makes setting and reverse engineering this risky and potentially error prone. One realtivly easy workaround to do this is to use some OWA automation code to use the method OWA uses to set this property. I've used this type of thing before to enable junkemail filtering on 2007 in OWA see

Using the MSXML2.ServerXMLHTTP.6.0 object this object is included with the Microsoft XML Parser (MSXML) and is a better choice for this script because it firstly supports the ability to ignore any SSL errors that might happen (eg self signed Certs, Alternate names etc) and it also handles dealing with the Forms Based Authentication cookie without the necessity to add additional code. The code still needs to perform the synthetic forms logon this works similar to 2003 with a few URL tweaks.

Dealing with the Language form for users who have never logged on to OWA before. Because this script is simulating a user in OWA if the mailbox your trying to set the junk email settings has never been logged onto before in OWA then the default language form will be presented to the user (or the script in this case) asking the person to choose there timezone and language. What this script does to cater for this is that it looks for this form in the response if it finds the form it then uses 2 regular expressions to parse the default values from the form and then posts these values. One problem this creates is that the user will nolonger be shown this form when they first logon anymore this may or may not be a problem for you. If you need for this form to still appear at first logon there are two options the first is to delete the OWA storage object in the root of the mailbox using WebDAV or Neil Hobson posted another method on the Exchange Blog.

The operation of the script is pretty simple after logging in it tries to post to the following URL QueryString in the Target Mailbox “ev.owa?oeh=1&ns=Options&ev=SaveGenOpts” with a body

<params><anrFst>0</anrFst><thmId>& themeID &</thmId><optAcc>0</optAcc></params>

The themeID is the interger of the ThemeID to set within 2007 the following intergers represent the default themes

0 Seattle Sky
1 Carbon Black
2 Xbox Theme
3 Zune Theme

To use this script you need to hard code the username and password of a user that has been give delegate access to the target mailbox using something like this in the Exchange Command Shell

Add-MailboxPermission –Identity ‘Mailbox’ –User ‘User’ –AccessRights FullAccess

Or has been given Send As and Receive As rights on the target mailbox. Basically the user needs to be able to open the target mailbox as another mailbox in OWA you can test if the account you want to use is going to be work by testing this yourself in OWA. Its also important that the account that you want to use has logged onto OWA once as well this is because the Language form would be presented to this user the first time the user tries to logon to OWA while the script caters for this for the target user it doesn’t do it for the source so this would cause a timeout error in the case the source user has never logged on to OWA. So before using the script you need to configure the following variables

snServername = "ServerName"
mnMailboxname = "mailbox"
domain = "domain"
strpassword = "password"

In the snServername variable make sure you use the servername of your CAS server this may or may not be different from your mailbox server.

The following variable is for the target mailbox you want to set the junkemail setting on this should be the primary SMTP address of the target mailbox

Targetmailbox = ""

The scripts output is pretty verbose you should see the full response headers outputted for each request the script make this helps if you ever need to diagnose why the script isn’t working

I’ve put a downloadable copy of the script here the script itself looks like

snServername = "servername"
mnMailboxname = "mailbox"
domain = "domain"
strpassword = "password"

Targetmailbox = ""

strusername = domain & "\" & mnMailboxname
szXml = "destination=https://" & snServername & "/owa/&flags=0&username=" & strusername
szXml = szXml & "&password=" & strpassword & "&SubmitCreds=Log On&forcedownlevel=0&trusted=0"

set req = createobject("MSXML2.ServerXMLHTTP.6.0")
req.Open "post", "https://" & snServername & "/owa/auth/owaauth.dll", False
req.SetOption 2, 13056
req.send szXml

reqhedrarry = split(req.GetAllResponseHeaders(), vbCrLf,-1,1)
for each ent in reqhedrarry
wscript.echo ent

Call updateTheme(Targetmailbox,3)

Sub updateTheme(mbMailbox,themeID)

xmlstr = "0" & themeID & "0"
req.Open "POST", "https://" & snServername & "/owa/" & mbMailbox & "/ev.owa?oeh=1&ns=Options&ev=SaveGenOpts", False
req.setRequestHeader "Content-Type", "text/xml; charset=""UTF-8"""
req.setRequestHeader "Content-Length", Len(xmlstr)
req.send xmlstr
wscript.echo req.status
reqhedrarry = split(req.GetAllResponseHeaders(), vbCrLf,-1,1)
for each ent in reqhedrarry
wscript.echo ent
If InStr(req.responsetext,"name=lngFrm") Then
wscript.echo "Mailbox has not been logged onto before via OWA"
'Create a regular expression object
Dim objRegExp
Set objRegExp = New RegExp

objRegExp.Pattern = "


John said...

Hahaha, SWEET!

Thanks very much Glen, you made my day :P

John said...

Hi Glen, I have strange behavior, maybe you can shed some light on this. Implementation of this was very easy, I did make this part slightly clearer..

newthemeID = "5"
wscript.echo "Attempting to set theme to " & newThemeID
Call updateTheme(Targetmailbox,newthemeID)

Anyways, that aside I tested on a test user and it worked perfect, so I thought, lets test it on a bunch of users..

So I tested another user, username tes.testy.testy, same domain, entered the password, entered the targetmailbox, checked both values against get-mailbox | fl and tried owa log in, owa log in worked fine.

When I run the app I get response:
Attempting to set theme to 5
Theme ID: 5

A working user displays a 200

I googled 440 and it appears my perms are wrong, how could this be though? I can log in into OWA fine, domain, username, password and targetmailbox is correct.

I'm a bit baffled! It's almost as if someone stuck a sock in me!

Glen said...

If your getting an error in this part of the script it means the inital user that your trying to use is failing to logon. This user must have an Exchange Mailbox for this to work properly. The other problem could be if the users are on seperate Exchange Servers. A typo in the username password or domain varible would do this as well

John said...

checked all those bits, to the point where i logged in/out as this specific user. Recreated the users account and it was fine.

Not going to lose any sleep over this one, I consider it working flawless. I'm using this to set a theme on a user based on if the user is male/female and a child/teacher.

It was warmly welcomed by our users! :)

Anonymous said...

Thanku Glen,
Thankyou very much

Anonymous said...

Thanks for the script. For non-english organizations (like mine) I added the following line right after req.Open "POST", "https://" & snServername & "/owa/" & mbMailbox & "/lang.owa", False

req.setRequestHeader "Accept-Language", "es-ar"
This prevents OWA renaming Inbox/Outbox/etc folders

Anonymous said...

I'm having a "400 Bad Request" problem with a bulk modification (using modified script)

Set colAccounts = GetObject("WinNT://" & domain & "")
colAccounts.Filter = Array("user")
For Each objuser In colAccounts
UpdateJunk( & "@" & domain)

After +/- 100 users the scripts starts giving 400 status and mailboxes are not modified. Any ideas?

Glen said...

Try breaking it into two scripts what might be happening is your hitting a connection limit because VBS is not clossing the session properply. If you break this into two scripts when the Mailbox script finishes executing it should be out of scope. This has worked for me in the pass with Mapi scripts.