Thursday, May 31, 2012

Visual Basic Script to make calendar objects public

Well those fine, fine people at Oracle make the default PRIVATE for ICS exports in Oracle Calendar Server 10.x.

SO we have options for making our process make them NON-PRIVATE if you wish.

OR if you want to migrate it as private and then change it, this VB script will help.

Here is a VB Script that will make items public

Dim appOutlook As New Outlook.Application
Dim OutlookItems As Outlook.Items

Public Sub ClearCalendarItemsPrivateFlag()
Set OutlookItems = appOutlook.GetNamespace("MAPI").GetDefaultFolder(olFolderCalendar).Items

For Each appointment In OutlookItems
    appointment.Sensitivity = olNormal  'or olPrivate if you want to turn it back
Next appointment

End Sub

Saturday, May 26, 2012

Exchange 2010 Permissions summary and debugging

Depending on the situation there are four permissions your service account must have to function successfully in either a migration or using Sumatra calendar tools:

1.       Impersonation
2.       Full access
3.       Read access to the GC
4.       Other details: Allow Log On Locally

In which situations are these permissions used?

This summarizes the types of permissions you must use when using Sumatra calendar technology.
Use Permission
Migrating Calendar Data into Exchange

Resource mailboxes are Disabled accounts by default, so in a full-state calendar migration they are ENABLED temporarily so that the Sumatra process can populate data correctly.
“Faster simpler” ICS calendar migration to Exchange

Using the SuHoliday cmdlet or the Sumatra Pump on users
Putting holidays into user calendars requires only impersonation
Using the SuHoliday cmdlet or Sumatra Pump on resources
Full access
Why Full access in this case?  Impersonation will not work unless you enable the accounts.  In a migration there are many reasons for doing this, but for holidays that is a wasteful extra step.  Use Full access.
Terminating an Existing User
It’s basically a migration in reverse, so you use the same permissions as a migration
Removing broken meetings from resource or user calendars
Full access
Don’t mess around in this case.  You’re trying to scrub out bad data, don’t let low permissions get in the way of a fast job.


Impersonation grants the service account permission to ‘send-as’, and ‘receive-as’ the user account.   Note, however, that impersonation works only when the account is enabled.  For disabled accounts you will need full access.
To impersonate in Exchange 2010, create a new ManagementRoleAssignment (called “_suImp8”) for your service account (called “exsu”.)

Full Access, Send-as, Receive-as

Full Access grants the service account permission to access the user account.   Full access allows you to read from and write to folders in both enabled and disabled accounts.   If you are just cancelling meetings from the conference room, full access is sufficient.  If you want to send mail on behalf of a disabled user/room, you will also have to grant send-as receive-as (see the next section)
To grant your service account (called “exsu”,)  full access for a room (“crar210q”), use the add-mailboxpermission cmdlet.
    -Identity: crar210q
    -User: exsu@cod.sumatra.local
    -AccessRights: FullAccess
    -InheritanceType: All

Note that group policies sometimes prevent permissions from being inherited.  Please use Active Directory Users and Computers (ADUC) to ensure the permissions were set!  Find the account (crar210q) and right-hand click to obtain properties.  Select the security tab, then advanced. (If the security tab is missing, select Advanced Features under View.)   You can check the permissions, or the effective permissions.  You should not see deny checked!

Add Send-as, Receive-as

If you have to add send-as receive-as, here is the commandlet
    “CR 101B”
    -user: exsu
    -AccessRights:  genericall
    -ExtendedRights: "receive as","send as",
    -InheritanceType: All      

Read access to the Global Catalog

Many enterprises grant access to the global catalog if the user is a member of the domain.  If login is failing, anonymous access is probably disabled (since Windows 2000 DCs).  Make sure you are an authenticated user.

Other Details: Allow log on locally                       

Make sure your service account is allowed to log on locally (as in the Local security policy, or if you have multiple machines, set via Group Management Policy, screen shot below.) Otherwise you will generate a 401 error.
Note that in the example above we have both a specific service account and a Group of Service accounts.  Using groups in this way is an effective means of managing several accounts if you need to segment them for Exchange data insertion.

Debugging Exchange 2010 Permissions Problems

Setting permissions correctly is one of the largest stumbling blocks in the process.    Here is a list of the HTTP errors, and ways to debug (and fix) permissions.

Most Likely Issue
Service account not allow to “log on locally”
Grant permission to “log on locally” via group or local security policy
The CAS and Mailbox servers are not members of Windows Authorization Access Group.
Add all computers as members to “Windows Authorization Access Group” in ADU&C.
BASIC authentication is not enabled for the EWS virtual directory in IIS
Set Basic authentication in IIS; remember to restart IIS
The "SERVICE ACCOUNT" is not authorized to submit requests to the CAS Server
Create a new-ManagementRoleAssignment, and grant ApplicationImpersonation rights  to the service account.  Also remember to check the service account creds to ensure they password is correct. Paste the "ews url" into a browser. Enter the service account creds, when prompted. Do you see a EWS WSDL page? (Note: this could show up as a 500 error in some instances.)
The "test user" does not exist in Exchange
is not mailbox enabled
Verify account exists in the domain, it is enabled, a mailbox user (try to access the account in OWA using the service account credentials).  If the account is disabled, did you grant “fullAccess” to the service account?
The "SERVICE ACCOUNT" cannot impersonate the "test user"
Verity there is a management_role assignment "ApplicationImpersonation" (Ex10) or ExtendedRights:"ms-Exch-EPI-Impersonation","ms-Exch-EPI-May-Impersonate" (ex07) for the SERVICE ACCOUNT that is applied to the server or the user you are attempting to test.
Start with IIS Basic authentication on the EWSvirtual directory. It’s the easiest to see / fix.

Basic debugging protocol – 401 error

Open a browser window, and try to open you EWS url.  If you typically point to the load balancer, point to one CAS server instead.  Try to open the ews url e.g., http://ex10/ews/exchange.asmx.   You should be prompted for credentials.  Enter the service account credentials.  If the credentials are rejected, your service account may not be allowed to log on locally.  If you can login, try to insert a “test” appointment using suExchange.  If you see a 401, it will be due to basic authentication not set OR the CAS/MBX server(s) are not members of windows authorization access group.

Issue: Service account not allowed to log on locally.

Here’s an easy way to confirm you cannot log on locally.  Go to the cas server you pointed to in the EWS url, and open up the Security event log.  Search for event ID 4625, keyword Audit Failure.  You’ll know you have to grant log on locally if you see your service account, with failure information “the user has not been grated the requested logon type at this machine”.   If so, allow the service account to log on locally via a group policy or local security policy.

Issue: Basic Authentication not set

Look in the IIS logs.  If you see a 401 error, check IIS.  If basic authentication is disabled, enable it. Remember to cycle IIS:  “iisreset /noforce.”

Issue: Computers are not members of Windows Authorization Access Group

If you are still getting a 401 error, ensure that ALL exchange computers and domain controllers are members of windows authorization access group.

Basic debugging protocol – 500 error

Issue: Service account does not have impersonation permissions or full access

If you are still getting a 401 error, try logging into an active end user’s mailbox via OWA (like your own!) using the service account credentials.  If you see an error in OWA:
Check the Application event logs on the CAS server for Event ID 17. If you do, then create a “New-ManagementRoleAssignment” to grant the service account ApplicationImpersonation permissions (see “Impersonation,” above.)

Wednesday, May 16, 2012

Throttling in Hosted Exchange

Microsoft does not close a window without slamming a door and bricking you in.

One of our least favorite topics again comes to the fore: Throttling in hosted Exchange.

Redmond claims these changes are customer-driven, which may or may not be so, but from the standpoint of customers who want to migrate a lot of calendar data into Hosted Exchange, these modifications are like getting a grenade tossed in your lap.

In an on-premises migration it's straightforward to turn these limits off.  Going into Hosted you're at the mercy of Microsoft (good luck with that) or the cleverness of your developer (yes, we can handle this).

If like me you find an hour long video of Exchange Web Services Affinity and Throttling as and act of stultification on the order of Hypnotoad, you can read most of the gist of this at More throttling changes for Exchange Online.

Our recommendations going forward for Hosted Migrations:   

During validation, point to different CAS servers to reduce CAS-server throttling (our code is going to need to change to do this)

During an insertion, use MULTIPLE service accounts which means using parallel insertion processes and point these to different CAS servers.  We're set up for this already, but we now recommend it in smaller migrations than we used to.

During migration, set the batch input to at least 50 calendar objects.

Props to Andrew at UC Irvine who called this to our attention by stepping on the landmine in test last week.


Wednesday, May 02, 2012

Microsoft Access 2010 x64 database access

As more Sumatra customers stand-up x64 systems, they hit the "Unrecognized database format" error.  The issue:  There isn't an x64 MS Access driver.  But there is a solution:   

Download the 2007 Office System Driver: Data Connectivity Components

Choose Microsoft Office 12.0 Access Database Engine OLE DB Provider!!

If you are editing the suExchange _config.xml file, you'll find those settings in the DatabaseProvider tag.  The choices are:

x64: Provider=Microsoft.ACE.OLEDB.12.0;Data Source=
or x32: PROVIDER=Microsoft.Jet.OLEDB.4.0;Data Source=