Entourage 2008, Web Services Edition released!

Entourage 2008, Web Services Edition, is an incremental update to Entourage 2008 which jettisons dependance upon WebDAV in favor of Exchange Web Services.  I know from using the beta that this fixes the generational suffix bug and several other bugs related to name resolution. This version also adds client-side logging capabilities.

Microsoft Office 2008 for Mac 12.2.1 is required for installing this update. It is available from the Downloads section of http://www.microsoft.com/mac.

UPDATE: Note that there is a flaw in the implementation of AutoConfigure. I had pointed out the flaw to Microsoft during beta testing, and they claimed to have fixed it, but have apparently not done so.  AutoConfigure fills in the LDAP server field in the account configuration with the name of a domain controller (randomly selected from the pool of available DCs). There are two problems with this in our environment: 1) Our DC’s are not accessible from off-campus, so directory lookups will fail for off-campus Entourage users. 2) The DC’s use self-signed certificates for the SSL encryption of the LDAP connection, which Entourage will not trust.

In our environment, the workaround for this is to manually configure the LDAP server setting with  directory.austin.utexas.edu (the publicly-reachable Netscaler alias for our DCs, protected with a Verisign cert), and tell AutoConfigure to stop trying to configure the settings. (Other settings pulled by the process should work fine.)

Strictly speaking, this is a design flaw on the server side of the AutoConfigure process, as there is no way to configure it to return a specific address for the LDAP server such as our Netscaler alias, despite the ability to configure URLs for other services.

Enumerating Sharing Permissions via EWS Managed API in PowerShell

The following PowerShell script enumerates the sharing DACLS on the Inbox and Calendar of the user under whom the script is running.  I’ve not yet attempted to enumerate the permissions for a different user. I included the “$perms[$i].UserID | fl *” line to illustrate why I use an IF-THEN construct.  The default permission throws an odd wrinkle into the mix.


#---------------------------------- ews_get_perms.ps1 ------------------------
$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\1.0\Microsoft.Exchange.WebServices.dll"
[void][Reflection.Assembly]::LoadFile($dllpath)

$service = new-object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)
$uri=[system.URI] " https://YOUR.EWS.FQDN/ews/exchange.asmx"
$service.Url = $uri

$inbox= [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox)

$perms = $inbox.permissions

"`nPermissions on Inbox:"

for ($i=0;$i -le ($perms.Count - 1);$i++) {
if ($perms[$i].UserId.DisplayName -eq $null) {$user=$perms[$i].UserId.StandardUser}
Else {$user=$perms[$i].UserId.DisplayName}
$perms[$i].UserID |fl *
"User : $user"
"CanCreateItems : $($perms[$i].CanCreateItems)"
"CanCreateSubFolder : $($perms[$i].CanCreateSubFolders)"
"IsFolderOwner : $($perms[$i].IsFolderOwner)"
"IsFolderVisible : $($perms[$i].IsFolderVisible)"
"IsFolderContact : $($perms[$i].IsFolderContact)"
"EditItems : $($perms[$i].EditItems)"
"DeleteItems : $($perms[$i].DeleteItems)"
"ReadItems : $($perms[$i].ReadItems)"
"PermissionLevel : $($perms[$i].PermissionLevel)"
"DisplayPermissionLevel : $($perms[$i].DisplayPermissionLevel)"
"-----------------------------------------------"
}

$cal=[Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Calendar)

$perms = $cal.permissions

"`nPermissions on Calendar:"

for ($i=0;$i -le ($perms.Count - 1);$i++) {
if ($perms[$i].UserId.DisplayName -eq $null) {$user=$perms[$i].UserId.StandardUser}
Else {$user=$perms[$i].UserId.DisplayName}
$perms[$i].UserID | fl *
"User : $user"
"CanCreateItems : $($perms[$i].CanCreateItems)"
"CanCreateSubFolder : $($perms[$i].CanCreateSubFolders)"
"IsFolderOwner : $($perms[$i].IsFolderOwner)"
"IsFolderVisible : $($perms[$i].IsFolderVisible)"
"IsFolderContact : $($perms[$i].IsFolderContact)"
"EditItems : $($perms[$i].EditItems)"
"DeleteItems : $($perms[$i].DeleteItems)"
"ReadItems : $($perms[$i].ReadItems)"
"PermissionLevel : $($perms[$i].PermissionLevel)"
"DisplayPermissionLevel : $($perms[$i].DisplayPermissionLevel)"
"-----------------------------------------------"

No LaTeX support? Drat.

Sadly, UT’s WordPress implementation does not include support for LaTeX tags.  I’ve submitted a suggestion to add such support. I’m thinking that it will greatly improve the appeal of this service to faculty and students in math, science, and engineering disciplines.  I’ve also posted an example on WordPress.com of what such support can do.

If such support were in place, the following code would show the LaTeX logo:

$latex \LaTeX$