Alt-N Discussion Groups > MDaemon Discussion Groups > MDaemon API > Programmatic Access To Calendar Data From .NET

 [F] Alt-N Discussion Groups  / MDaemon Discussion Groups  / MDaemon API  /

Programmatic Access To Calendar Data From .NET

Hi, I'd like to create/read/update/delete a MDaemon users calendar events (appointments) in an automated way from a C#.NET application running on a computer that is not the same computer that MDaemon is running on.

I contacted tech support from the vendor that sold MDaemon to my client but they told me to post in the community forums because the dev(s) monitors the forums and that would be the best hope to get an answer to my query.

The use case is that a business that I've written custom management software for is using MDaemon and they want me to automatically create appointments in each users MDaemon calendar to sync up with the appointments stored in my custom software, which is also pushing those appointments to a google calendar successfully.

In looking through posts here and the documentation i first thought i could write a C# wrapper around the MDCalendar.dll C++ (COM?) library, however the documentation in the MDaemon\API\MDCalendar.html folder is incomplete and i couldn't find an online reference.
I also see here that there is an XML API but in looking at the .htm files in the XML API folder i don't see any reference to calendar events.
I did notice that the events appear to be stored in MDaemon\User\Domain\User\Calendar.imap, in the Calendar.mrk file and can be parsed, however i'm not sure it's safe to edit that file directly to create/edit events.

My question is what is the best method, if any, to interact with the MDaemon calendar programmatically?

  (older msg: 6)All MessagesOldest ItemsOlder ItemsNewer ItemsNewest Items

Keith Personett - Jan 17, 2020 9:51 am (#7 Total: 11)  


Photo of Author
Keith Personett
Posts: 82

If you are creating a service to modify data in various mailboxes, you will be making FO and IO calls with the path attribute beginning with MAILBOX/ (as opposed to PRIVATE/) and the account attribute must be specified. The Account making the API request has to have permission to access the folders and items. This can be done one of two ways.

1) Your service is using an MDaemon Account, which has permissions to all of the calendar folders it is modifying. This means can be easily broken by a mailbox owner removing that permission, and requires the use of a licensed MDaemon account.


2) Your customer, using a Global Admin Account, via the XML API, could create an API Service account (https://{Server}:{Port}/MdMgmtWS?GetSample=ServiceAccount_Create_RES.xml ). Any management of API Service Accounts requires Global Admin Permission, which is why perhaps your customer would have to do this for you or provide you with a temporary Global Admin account to do it yourself. This creates an XmlApi Logon that is not an MDaemon User, and has functionality limited to specific operations and domains. In the ServiceAccountCreate request, you should…
a. include any domains it requires access to.
(Domain delete="0" update="0" append="0" read="1" list="1" action="allow" name="avengers.int"/)
(Domain delete="0" update="0" append="0" read="1" list="1" action="allow" name="heroes4hire.int"/)
b. Include any Operations that it is allowed to perform such as
(Operation delete="0" update="0" append="0" read="1" list="1" name="FolderOperation"/)
(Operation delete="1" update="1" append="1" read="1" list="1" name="ItemOperation"/)
c. After you create the API Service account, you would then issue a ServiceAccountUpdate request with the Account ID and an empty PasswordReset Element (see https://{Server}:{Port}/MdMgmtWS?GetSample=ServiceAccount_PwReset_RES.xml ). This will generate and provide you with the password for the service account.
d. Now you have an API logon that is strictly limited to specific functionality on specific domains, which cannot be broken by a mailbox owner messing with permissions.
e. Service accounts authenticate the same way that normal MDaemon logons authenticate, basic authentication, just no domain value.
i. ie. {gQ4mJ80F-fUin-W29H-AzR4-8db44AmF0t2O:{6oMwI1VO-47Q5-e9O7-ZK62-zJvZg5PrSN89}

Both ways have specific benefits. The benefit of using an API Service Account, is that as users/mailboxes are added, it doesn’t require additional setting to ensure that it works. As long as that new mailbox is within a domain that the service account is allowed to access, it will work.

  (newer msg:4)All MessagesOldest ItemsOlder ItemsNewer ItemsNewest Items


Read New | Search


Email to Admin

You are visiting as a Guest user.