Saturday, March 29, 2008

Class library helper for setting Calendar Permission via Powershell and Exchange 2007

I posted something a while ago that tried to explain how you can go about setting calendar rights using the new features in EWS included in Exchange 2007 SP1. Unfortunately from the feedback i got it seemed to confuse people more than help it seemed most people where interested in resetting the default calendar permissions especially in regards to the new Freebusy Acl’s that where included in Exchange 2007/Outlook 2007. The freebusy rights pose a special challenge because the normal scripts like CDO 1.2 or Pfdavadmin can’t be used to set these particular rights you need to use either the Outlook 2007 OOM or EWS. So I decided to come up with a helper class similar to the OOF helper class I wrote before that would allow people to change the rights on a calendar just using a couple of lines in Powershell.

Because I already has a namespace for the OOF helper I decided to fork that code into a new namespace and library and I thought that I’d be able to reuse a lot of what I’d done before.... But the library turned out to be a lot more complex to get working for a number of reasons and required a lot of extra logic to get the library to behave the way I wanted to (but hey go hard or go home). How does it work well lets take a walk though and I’ll try to explain. Firstly if you want to use the library in Powershell you need to load it with a cmd such as

[void][Reflection.Assembly]::LoadFile("c:\temp\EWSUtil.dll")

Then you can actually create an object using the class library you just loaded when you create the object you need to specify some parameters that will be used to query EWS. The only mandatory parameter is the email address the optional parameters control how the object will work with EWS and how it handles authentication and which CAS it will use. The first parameter is the impersonation parameter which is a Boolean that controls whether the object will use EWS impersonation to access mailboxes or just use Delegate access (when I talk about delegate access I don’t mean delegated Exchange Admin access I mean either Outlook delegates or rights assigned via add-mailboxpermission). EWS impersonation comes in handy and is a more secure way of giving rights to an account to do a job such as changing calendar rights for every use on a server see http://msdn2.microsoft.com/en-us/library/bb204095.aspx for giving an account EWS impersonation rights.

The next three parameters are for the username,password and domain if you want to specify the user context you want this object to run under. This allows you to use this library on a machine that isn’t a member of the domain or run the library as a user that’s different from the currently logged on user. The last parameter is for the URL of the CAS Server to use this is important if you want to run the script from a machine that isn’t a member of the domain the Exchange Server is a member of. By default if you don’t specify this value the Library will try to look up active directory for the autodiscovery address and then try to do a Autodiscover request to find the EWS url based on the email address entered. Once you have everything worked out you need to run a line like this to create a calendar utility object.

$calutil = new-object EWSUtil.CalendarUtil("fred@domain.com", $false, "admin", "password#", "domain", "https://servername /EWS/Exchange.asmx")

Issuing this command will cause the GetFolder request to be issued to the server and it will retrieve the current calendar folder permissions and populate a generic list of Calendarpermssion objects.

This is where we encounter our first caveat as I said in a previous post the permission roles you set in Outlook don’t reflect the permissions level returned by EWS. So for most of the Outlook Roles you set you would see that as a custom permission in EWS (apart from FreeBusy rights which are reflected correctly). To work around this I created a few helper routines to convert the custom permissions that EWS returns back to the appropriate Outlook Roles which is handy if you’re trying to document or check the permissions that have been set via Outlook. And also some helpers so when you want to set permissions instead of using the EWS calendar permission that will be reflected as Custom permissions when viewed in Outlook you will see the correct Outlook role set. This is a hard one to explain its just one of the current nuances of EWS. An example of using one of the helper routines to set an ACE to an outlook role for a user your adding to the calendar DACL you would need to use one of the following lines depending on the Outlook Role you wanted to set.

$calutil.CalendarDACL.Add($calutil.NonePermissions(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.FreeBusyTimeOnly(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.FreeBusyTimeAndSubjectAndLocation(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.Reviewer(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.Contributer(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.AuthorPermissions(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.NonEditingAuthorPermissions(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.PublishingAuthorPermissions(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.AuthorPermissions(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.EditorPermissions(“user@domain.com”))
$calutil.CalendarDACL.Add($calutil.PublishingEditorPermissions(“user@domain.com”))

If you want to set permissions for the default user or anonymous user on the calendar instead of specifying the email address of the user you need to just put default or anonymous

eg $calutil.CalendarDACL.Add($calutil.FreeBusyTimeAndSubjectAndLocation(“default”))

Once you have added or removed the ACE you wanted to you then just call the update method eg

$Calutil.update()

Another quick sample if you want to output the default permissions and anonymous permission for a users calendar you can do the following. This shows an example of using the enumOutlook helper to get the Outlook Role that has been set.

[void][Reflection.Assembly]::LoadFile("c:\EWSUtil.dll")
$calutil = new-object EWSUtil.CalendarUtil("user@domain.com", $false, "user", "password", "domain", "https://servername/EWS/Exchange.asmx");
for ($cpint=0;$cpint -lt $calutil.CalendarDACL.Count; $cpint++){
if ($calutil.CalendarDACL[$cpint].UserId.DistinguishedUserSpecified -eq $true){
if ($calutil.CalendarDACL[$cpint].UserId.DistinguishedUser -eq [EWSUtil.EWS.DistinguishedUserType]::Default){
"Default " + $calutil.enumOutlookRole($calutil.CalendarDACL[$cpint])
}
if ($calutil.CalendarDACL[$cpint].UserId.DistinguishedUser -eq [EWSUtil.EWS.DistinguishedUserType]::Anonymous){
"Anonymous " + $calutil.enumOutlookRole($calutil.CalendarDACL[$cpint])
}
}

}

A few things about the update method when update is called it will first loop through the generic ACE list and build a Calendarpermission set to be used in a EWS update folder operation. Because there are no verification routines in the List add methods it will go through and make sure you don’t have any duplicate ACE's in the list say if you wanted to set the default permission on a calendar and instead of changing the current ACE you just added a new ACE for the default user. The update routine will find the duplicate ACE's and will use the last one added to the list which will overwrite the old ACE.

To demonstrate the use of this library I’ve put together a little powershell GUI script the will allow you to enumerate all the Default calendar permissions for every user on a server and set them to something else if you so desire. I’ve posted this separately here.

I wish I had more time to document this properly and I will try to update this post when I can. The code itself is very untested and I don’t consider it stable and or safe for use in a production environment I can only recommend that you use it in a test/dev environment and as a guide to building your own applications. I’ve include a complied DLL as well as the full source so you can look/debug as you please. If you do spot any major bugs and things I’ve done wrong or that could be done better please let me know so I can update the source.

I’ve put a download of the source and dll here the update function looks like

Additional -- Added after problems dicovered

One important and potentially frustrating point for anybody who wants to set permissions on the calendar folder in a mailbox with any Exchange API that allows you to modify the folder DACL’s is that you also need add the same ACE your adding (or modifying) to the FreeBusy Data folder which is one the NON_IPM_Subtree Root folders in a mailbox explained in this KB. Exchange Web Services is no exception to this rule and accessing the NON_IPM_Subtree folders isn’t as straight forward as normal mailbox folders but here’s a method for accessing the freebusy folder and modifying the DACL.

So what happens now when you create the object the code will try to retrieve the free/busy folder rights and a separate generic list object is created that contains the current Free/busy folder ACE's called FreeBusyDACL. Because as i said with this DACL you need to use a different type of ACE their are separate ACE objects defined eg

$calutil.FreeBusyDACL.Add($calutil.FolderEmpty(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderReviewer(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderContributer(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderAuthorPermissions(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderNonEditingAuthorPermissions(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderPublishingAuthorPermissions(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderAuthorPermissions(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderEditorPermissions(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderPublishingEditorPermissions(“user@domain.com”))

What you will need to do is duplicate any operations that Add or Remove ACE's to the CalendarDACL to also now do the FreeBusyDACL eg

$calutil.CalendarDACL.Add($calutil.EditorPermissions(“user@domain.com”))
$calutil.FreeBusyDACL.Add($calutil.FolderEditorPermissions(“user@domain.com”))

When you run the update method it will update both DACL's

40 comments:

Anonymous said...

The source/dll link is an empty 0k zip file. Any other place I can download the dll?

Glen said...

Sorry i updated the DLL the other day and my FTP program stuffed the file up. It should be fixed now.

Just a quick note someone emailed me about a problem this morning so this library may get update again in the next couple of days.

Cheers
Glen

Glen said...

Okay i've updated the library with some methods to also update the freebusy systems folder. Please read the additional section at the end of the post

Todd said...

Glen: I'm looking to simply change all users' calendars to allow reviewer access to all domain users.
In Domino this is a two second process for an Admin; in Exchange 2007 SP1 you need a programmer or eye of newt.
I know I can do this through PFDAVAdmin, but it scares me to rely on a tool that requires .NET 1.1 Framework now that we're on Vista.
I saw your C# code, but that looks like it only works if you pass the target mailbox user's credentials?
Am I missing something? Do you have a Powershell or C# example of how to do this?
Thanks so much--the site is great!!!

Glen said...

You can use Impersonation which allows you to assign one user that can impersonate every mailbox within the mailbox store see http://msdn.microsoft.com/en-us/library/bb204095.aspx. The library does cater for this type of authentication.

Cheers
Glen

Anonymous said...

Hi,
I seems that your link to download the GUI powershel sample is broken...
Thanks !

Glen said...

Okay thanks for that i've fixed that link it should have been http://gsexdev.blogspot.com/2008/03/default-calendar-permission-powershell.html

Cheers
Glen

eugene said...

Glen,

I didn't find a method to set up "None" Permission for Free/Busy Folder.

Thanks,
Eugene

Glen said...

The equivilent is

calutil.FreeBusyDACL.Add($calutil.FolderEmpty(“user@domain.com”)

Empty creates an ACE with no permisssions.

Cheers
Glen

Eugene said...

Glen,

Many thanks for your reply to my previous post.
I found that $calutil.CalendarDACL.Clear() removes all DACLs from the set, but you mentioned earlier that there is a way to remove a separate DACL leaving others intact. How can I do it?

You blog is excellent.
Thanks,
Eugene

Glen said...

What happens when you create the object is the list of ACE's for that particular calendar are held in the $calutil.CalendarDACL generic List. To remove an ACE you need to loop though all the ACE in this List find that one you want to delete and then use the removeat method with the proper index value. eg something like this

for ($cpint=0;$cpint -lt $calutil.CalendarDACL.Count; $cpint++){
if ($calutil.CalendarDACL[$cpint].UserId.PrimarySmtpAddress -eq "user@yourdomain")
{
"Removing ACE " + $calutil.CalendarDACL[$cpint].UserId.PrimarySmtpAddress
$calutil.CalendarDACL.RemoveAt($cpint)

}

}
$calutil.update()

The same for FreeBusyDACL as well

Cheers
Glen

eugene said...

Glen,

Everything works fine except $calutil.CalendarDACL.Add($calutil.NonePermissions($PrimarySmtpAddress))
and $calutil.FreeBusyDACL.Add($calutil.FolderEmpty($PrimarySmtpAddress))
Both these methods install "Folder Visible" (according PFDAVAdmin) instead of "None".
PFDAVAdmin install "None" properly. There is no difference in $calutil.CalendarDACL[nmb]|fc for both cases ( PFDAVAdmin and yours). Bug?

Thanks,
Eugene

Glen said...

Hi Eugene

Not really a bug i've used the EWS CalendarPermissionLevelType.None mapping which tends to differ from what outlook uses (apparently these will merge some time in the future). What you can do is create your own Custom PermissionType instead of using the ones i defined. Is having it set to visable causing a problem ??.

Cheers
Glen

Eugene said...

Glen,

No, it's not a problem. But I have another kind of problem with the script being run from C#. In case of any error, there is no error message returned even though script started from Exchange Management Shell returns errors properly. I usually redirect error output as 2>&1 but this doesn't work in this particular case.

Thanks,
Eugene

Glen said...

What are the errors your getting ? This class library doesn't require the EMS unless you combining it with other EMS cmdlets you can run the code directly from a .NET project. The source is there also so you could just take the source and compile it into your own project.

Cheers
Glen

Eugene said...

Glen,

Adding permission rights for Anonymous doesn't work. Everything else works fine.
First I run
$calutil=new-object EWSUtil.CalendarUtil('PrimarySmtpAddress', $true, 'admin', 'password', 'domain' );
Then add Anonymous -> $calutil.CalendarDACL.Add($calutil.EditorPermissions(“Anonymous”))
DACL looks great (I checked)
Then -> $Calutil.update()
and get an error
System.Web.Services.Protocols.SoapException: An internal server error occurred.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream respon
Stream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
(...output cut)
Did you check your dll for Anonymous user? (I bet you did)

Thanks,
Eugene

Glen said...

It seems to work fine if the anonymous ACL exists on the folder but you can't add the anonymous ACL if it doesn't exist (i recieve the same error if i try this so i believe thats propabably the issue). Generally you shouldn't be modifying the Anonymous ACL (or removing it) but its possible to do either via Outlook or any other method. Once the ACE has been removed the only way to re add it that i know of is using PFDavAadmin. There is a discussion on the anonymous ACE in http://technet.microsoft.com/en-us/library/bb508858(EXCHG.65).aspx and using PFDAVadmin. The default ACE is better to use to grant everyone access to a particular calendar.

Cheers
Glen

google.10.Kofl said...

Awesome library.

Does it also work with groups (distribution lists)? For users its fine, but for groups we only get userid not found.

Group support would be THE killer feature for us.

Glen said...

You can add mail-enabled security groups using this fine. The issue is if you try to add a mail-enabled distribution group which is explained in http://support.microsoft.com/kb/941318/. You can only use a security group to set permissions on a folder. Previous version of Outlook allowed you to do both but a process in the background actually changes that Distribution Group to Security Group but Outlook 2007 and EWS just error out if you try to use a distribution group. There is also http://technet.microsoft.com/en-us/library/bb430793(EXCHG.80).aspx i've not sure what the affect with be with the library if you set this property.

Cheers
Glen

google.10.Kofl said...

We tried to add add mail-enabled security groups, but it wont work, users work fine:

3
Folder update error : A UserId was not valid.
EWSUtil.GetFolderException: Exception of type 'EWSUtil.GetFolderException' was t
hrown.
at EWSUtil.CalendarUtil.SetCalendarDACL()
at EWSUtil.CalendarUtil.Update()
EWSUtil.GetFolderException: Exception of type 'EWSUtil.GetFolderException' was
thrown.
at EWSUtil.CalendarUtil.SetCalendarDACL()
at EWSUtil.CalendarUtil.Update()

We tried the following security groups, which were email enabled:
Domain local groups
Universal groups
Global groups

We use the following code:

[void][Reflection.Assembly]::LoadFile("c:\swpool\Calendar-Permissions\EWSUtil.dll")

$strRootURI = "https://server.kd.local/EWS/Exchange.asmx"

$calutil = new-object EWSUtil.CalendarUtil("testuser@kd.com", $true, "", "", "", $strRootURI)
$calutil.CalendarDACL.Add($calutil.Reviewer("ALLIOCALENDAR@kd.com"))

$Calutil.update()

Any help would be really awesome.
Thanks,
Thomas

Glen said...

The only type of group that can be added with EWS is a Universal Security Group. If you create a new universal secrutiy group using EMC and try to add this you should find that it will work okay. This problem happens if groups have been converted by the method i mentioned before. One problem when this conversion happens is that it doesn't modify the msExchRecipientDisplayType which still remain at 1. EWS wont let you add a group unless the property value is 1073741833. If you have a group that has been converted to a Universal Security Group and that value of this property isn't set to 1073741833 then that usually the problem. What you can do is modify this property manually with ADSIedit. You should take great care when doing so and you should only every modify the property on a group that is already a Universal Security Group dont change this value for Global Groups.

Cheers
Glen

google.10.Kofl said...

Awesome, setting the msExchRecipientDisplayType to1073741833 worked flawless. Thanks a lot.

google.10.Kofl said...
This comment has been removed by the author.
google.10.Kofl said...

Hm, sorry, but we have another strange thing:

$calutil = new-object EWSUtil.CalendarUtil("test2.test@domain.com", $true, "", "", "", $strRootURI)
$calutil.CalendarDACL.Add($calutil.Reviewer("user2.user@domain.com"))

works fine,

but

$calutil = new-object EWSUtil.CalendarUtil("user2.user@domain.com", $true, "", "", "", $strRootURI)
$calutil.CalendarDACL.Add($calutil.Reviewer("test2.test@domain.com"))

fails:
4
Folder update error : A UserId was not valid.
EWSUtil.GetFolderException: Exception of type 'EWSUtil.GetFolderException' was t
hrown.
at EWSUtil.CalendarUtil.SetCalendarDACL()
at EWSUtil.CalendarUtil.Update()
EWSUtil.GetFolderException: Exception of type 'EWSUtil.GetFolderException' was
thrown.
at EWSUtil.CalendarUtil.SetCalendarDACL()
at EWSUtil.CalendarUtil.Update()

Both of them are on the same server and storage group.

Any input is really welcome,
Thanks,
Thomas

Glen said...

What does the ACL for user2.user@domain.com look like. Are there existing groups already on this DACL. If there are exsiting group on this DACL and the msExchRecipientDisplayType isn't correct then when the library tryies to update the DACL it will fail. The library doesn't append to the DACL it basically recreates it so existing entries can cause it to fail. You also need to make sure you allways use the primary SMTP address.

Cheers
Glen

Anonymous said...

Thanks a lot - thats it, there are existing groups with where added via other interfaces.

Thanks a keep up the good work.

Eugene said...

Glen,

to manage calendar resources, calendar folder must be created before, i.e. an account must be logged at least once. Is there a way to automate this procedure? ( I mean is there a PS command to logon to the account with some service account credentials thus creating a calendar folder?)

Thanks,
Eugene

Glen said...

The easiest method is generally just send the Mailbox a email which will then initilize all the default mailbox folders.

Cheers
Glen

Eugene said...

Glen,

what is a reliable method to figure out whether mailbox folders have already been created?

Thanks,
Eugene

Glen said...

if you use get-mailboxstatistics a mailbox that hasn't been initilized wont appear.

Cheers
Glen

Simon said...

Hi Glen
I have run into some issues with newly created room mailboxes. When I try to create the Calenderutil object I get:
$CalUtil = new-object EWSUtil.CalendarUtil("res1010@domain.local", $false, "ewssysaccount", "password", "DOMAIN", "https://CAS1.domain.local/EWS/Exchange.asmx")
Error During Getfolder request : The specified folder could not be found in the store.
EWSUtil.GetFolderException: Exception of type 'EWSUtil.GetFolderException' was thrown.
at EWSUtil.CalendarUtil.GetCalendarDACL(String emEmailAddress)
at EWSUtil.CalendarUtil.initlizeDACL(String EmailAddress, Boolean Impersonate
, String UserName, String Password, String Domain, String ewsURL)

I can confirm that they ewssysacocunt has Full Mailbox Access. I can open the calender in Outlook and add items with that account.

I can post the entire scritp if it would help.

Many thanks
Simon

Glen said...

Simon

I would say the problem is to do with Email address your trying to use eg "res1010@domain.local" doesn't look like it is the Primary SMTP address of this mailbox. Make sure that you use the Primary SMTP Address for the account the AD UPN wont work.

Cheers
Glen

Simon said...

Hi Glen,

I can confirm that it is the primary SMTP address I am using.
I have noticed that putting a long delay in the script (300seconds at the moment) before performing the web services stuff works fine. So it appears that there is something that is not entirely initialised when I try set the permissions via web services.
The breakdown of the script is as follows:
- Create a resource mbx
- Create 2 USGs (1 for BookInPolicy and 1 for Full Mailbox Access)
- Set DisplayName & some other stuff on resource mbx
- Get primary smtp of resource mbx and BookinPolicy USG
- Send initialisation mail to resource mbx
- Short pause
- Set-MaiboxCalenderSettings on resource mbx
- Set mailbox permissions on resource mbx (Here I am giving the ewssysaccount Full Mailbox Access on the resource mbx)
- LONG PAUSE HERE
- Web Services stuff here (set Author permissions on resource mbx)

Without the LONG PAUSE HERE the script fails with the error code I posted before.
Any idea what could be causing the need for the delay?

Many thanks for your time
/Simon

Anonymous said...

Glen,

can your dll assign calendar permissions not only to mailbox-enabled user but also to mail-enabled universal security group? I know PFDAVAdmin allows to do it and it's a good way to assign an identical calendar permission to a number of users.
Unfortunately, your dll reports "Folder update error : A UserId was not valid." and stops working.

Thanks,
Eugene

Glen said...

UserID was not valid error when adding group is because of a bug in Exchange 2007. The only type of group that can be added with EWS is a Universal Security Group. If you create a new universal secrutiy group using EMC and try to add this you should find that it will work okay. This problem happens if groups have been converted by the method i mentioned before. One problem when this conversion happens is that it doesn't modify the msExchRecipientDisplayType which still remain at 1. EWS wont let you add a group unless the property value is 1073741833. If you have a group that has been converted to a Universal Security Group and that value of this property isn't set to 1073741833 then that usually the problem. What you can do is modify this property manually with ADSIedit. You should take great care when doing so and you should only every modify the property on a group that is already a Universal Security Group dont change this value for Global Groups.

Cheers
Glen

Anonymous said...

Adding calendar permissions is not working for us.
We always get a SoapException with something about FolderID that are not correct ???

Anyone seen this?

$calutil.CalendarDACL.Add($calutil.Reviewer(“default”))
$Calutil.update()

System.Web.Services.Protocols.SoapException: The request failed schema validation: The element 'FolderChange' in namespace 'http://schemas.microsoft.com/exc
hange/services/2006/types' has invalid child element 'Updates' in namespace 'http://schemas.microsoft.com/exchange/services/2006/types'. List of possible el
ements expected: 'FolderId, DistinguishedFolderId' in namespace 'http://schemas.microsoft.com/exchange/services/2006/types'.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyn
cCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at EWSUtil.EWS.ExchangeServiceBinding.UpdateFolder(UpdateFolderType UpdateFolder1)
at EWSUtil.CalendarUtil.SetCalendarDACL()
at EWSUtil.CalendarUtil.Update()

Anonymous said...

Has anyone seen this error?
When trying to add permissions to a mailbox.
Something about a FolderID not specified.

This is the code:

[void][Reflection.Assembly]::LoadFile("c:\temp\EWSUtil.dll")
$calutil = new-object EWSUtil.CalendarUtil("user", $false, "adm", "pwd", "domain", "https://server.domain.com/EWS/Exchange.asmx");

$calutil.CalendarDACL.Add($calutil.Reviewer(“default”))
$Calutil.update()


This is the error:

System.Web.Services.Protocols.SoapException: The request failed schema validation: The element 'FolderChange' in namespace 'http://schemas.microsoft.com/exc
hange/services/2006/types' has invalid child element 'Updates' in namespace 'http://schemas.microsoft.com/exchange/services/2006/types'. List of possible el
ements expected: 'FolderId, DistinguishedFolderId' in namespace 'http://schemas.microsoft.com/exchange/services/2006/types'.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyn
cCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at EWSUtil.EWS.ExchangeServiceBinding.UpdateFolder(UpdateFolderType UpdateFolder1)
at EWSUtil.CalendarUtil.SetCalendarDACL()
at EWSUtil.CalendarUtil.Update()

Shlomi said...

Hi Glen,

Thanks for sharing this great library!

I'm trying to reset the permissions for "default" for all users.

What is the equivilent of $calutil.CalendarDACL.Add($calutil.FreeBusyTimeOnly(“default”))

for FreeBusyDACL?

FolderFreeBusyTimeOnly is not there.

Regards,

Shlomi

Nick said...

Hi Glen.

I'm trying to add the 'anonymous' setting of 'none' back to a user's calendar. Currently 'anonymous' is missing from the GUI permissions.

I haven't had any luck with the 'PFDAVAdmin.EXE' tool: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=22427

It this library a way to set this permission?

It looks like it's using EWS to interface with calendar permissions in Exchange 2007?

Anonymous said...

Hi Glen, great script! I was having same issue as Simon reported initially. It worked fine after first adding full mailbox access to the user spesified with user/pass/domain, via add-mailboxpermission cmdlet.