Pushing Calendar Events with the EWS API

We’ve had a need to populate users’ calendars with data from an internal FileMaker Database, so I dug around in the EWS API, and came up with a script that uses the FileMaker ODBC Connection, and the EWS API to accomplish the task:

First things first, we need to install the EWS Managed API on the machine that will run the script.

After the EWS Managed API is installed, we need to reference it in our PowerShell script:

Add-Type -Path “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”

Next, we need to set up a System.Net.NetworkCredential object for the account we’ll use to push these events.  This account must have at least modify permission on the target users’ calendar.

$Credentials = new-object system.net.NetworkCredential(“CalendarAccessAccount”,”SuperStrongPa$$w0Rd!”,”litware”)

Next, we need to Create anMicrosoft.Exchange.WebServices.Data.ExchangeService object:

$version = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013_SP1
$service = new-object Microsoft.Exchange.WebServices.Data.ExchangeService($version)

We don’t want to use the default credentials, Instead we want to authenticate using the service account specified earlier:

$service.UseDefaultCredentials = $false
$service.Credentials=$Credentials

And, presuming AutoDiscover is set up correctly in our domain, we want to let EWS figure out the server address, port, etc:

$service.AutodiscoverUrl(“TargetMailbox@litware.com”)

Next, we need to reference the user’s calendar (it’s really just a folder as far as the API is concerned):

$folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar, “TargetMailbox@litware.com”)

And finally, we build the appointment object:

$Appointment = New-Object Microsoft.Exchange.WebServices.Data.Appointment -ArgumentList $Service
$appointment.Subject = “Test111”
$appointment.Body = “Test111”
$appointment.Start = $(Get-Date).AddHours(6)
$appointment.End =$(Get-Date).AddHours(9)

Don’t forget to save it:

$appointment.Save($folderid)

 

All in all, we can wrap this up as a function:

Function CreateAppointment($User,$Credentials)
{
$mailboxName=$User
$version = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013_SP1
$service = new-object Microsoft.Exchange.WebServices.Data.ExchangeService($version)
$service.UseDefaultCredentials = $false
$service.Credentials=$Credentials
$service.AutodiscoverUrl($mailboxName)

$folderid = new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar, $mailboxName)

$Appointment = New-Object Microsoft.Exchange.WebServices.Data.Appointment -ArgumentList $Service
$appointment.Subject = “Test Subject”
$appointment.Body = “Test Body”
$appointment.Start = $(Get-Date).AddHours(6)
$appointment.End =$(Get-Date).AddHours(9)

$appointment.Save($folderid)

}

Now we can call the function from, say, with a loop so as to iterate through each user in a CSV:

$users = Import-CSV “Users.csv”

$Credentials = new-object system.net.NetworkCredential(“CalendarAccessAccount”,”SuperStrongPa$$w0Rd!”,”litware”)

Foreach ($User in $Users)

{

CreateAppointment $User $Credentials

}

 

More to come later on the FileMaker ODBC Connection…

FIM Portal No Access for FIM Admin Account

Today’s adventure with Forefront Identity Manager started when I was unable to log into the FIM portal.  Some digging revealed that the accountName attribute for my admin user had been set to null (probably from too much tinkering with sync rules).

I realized that the accountName was probably the issue by two indicators: there was no account name attribute for the FIM Admin object in the FIM Synchronization Service Manager application, and because the query below referencing the ObjectValueString table lacked some attributes. The change-fimadmin.ps1 script helped me determine these SQL sanity check queries.

I had already eliminated the usual suspects for not being able to access the portal (ObjectSID, MPRs, etc), so this stumped me for a little while

Anyway, I needed a way to get back in the portal (and I didn’t want to re-install), so I came up with this script that uses the FIM PowerShell modules to set the accountName attribute of the FIM Admin user (identified by the well-known admin user GUID).

I used the script on How to Use PowerShell to Set the Required Attributes for the FIM Portal Access as a starting point, modifying it to set only the accountName attribute.

$adminAccountName=”accountNameHere”

If(@(get-pssnapin | where-object {$_.Name -eq “FIMAutomation”} ).count -eq 0) {add-pssnapin FIMAutomation}

Function SetAttribute
{
PARAM($CurObject, $AttributeName, $AttributeValue)
END
{
$ImportChange = New-Object Microsoft.ResourceManagement.Automation.ObjectModel.ImportChange
$ImportChange.Operation = 1
$ImportChange.AttributeName = $AttributeName
$ImportChange.AttributeValue = $AttributeValue
$ImportChange.FullyResolved = 1
$ImportChange.Locale = “Invariant”
If ($CurObject.Changes -eq $null) {$CurObject.Changes = (,$ImportChange)}
Else {$CurObject.Changes += $ImportChange}
}
}
$curObject= export-fimconfig -uri $URI –onlyBaseResources -customconfig (“/Person[ObjectID='{7fb2b853-24f0-4498-9534-4e10589723c4}’]”)

$ImportObject = New-Object Microsoft.ResourceManagement.Automation.ObjectModel.ImportObject

$ImportObject.ObjectType = $curObject.ResourceManagementObject.ObjectType
$ImportObject.TargetObjectIdentifier = $CurObject.ResourceManagementObject.ObjectIdentifier
$ImportObject.SourceObjectIdentifier = $CurObject.ResourceManagementObject.ObjectIdentifier
$ImportObject.State = 1

SetAttribute -CurObject $ImportObject -AttributeName “AccountName” -AttributeValue $adminAccountName
$ImportObject | Import-FIMConfig -uri $URI -ErrorVariable Err -ErrorAction SilentlyContinue

 

After running this script, you should be able to log into the FIM portal again.

Helpful places to look also include the FIMService database.  Particularly the ObjectValueString and UserSecurityIdentifiers Tables.

 

The following query represents the values for the FIM Admin User, and should yield 7 rows(Attribute Keys 1,66,68,70,117,125,132)

SELECT TOP 1000 [AttributeID]
,[ObjectKey]
,[ObjectTypeKey]
,[AttributeKey]
,[SequenceID]
,[LocaleKey]
,[ValueString]
,[Multivalued]
FROM [FIMService].[fim].[ObjectValueString]

where ObjectKey =2340

The following query represents the SID, in HEX form, of the FIM Admin User, and should yield 1 row:

SELECT TOP 1000 [UserObjectKey]
,[SecurityIdentifier]
FROM [FIMService].[fim].[UserSecurityIdentifiers]
where UserObjectKey =2340