We currently have a specific format for how our email addresses are defined, based upon name. This system originated some time ago and is beginning to become a bit of a hindrance.
We would like to move to a new format, based along the line of
<first name initial><second name initial><last name>#organisation.com
However, we dont just want to rename the mailboxes etc, instead we're opting to keep the existing email addresses for all current users, but using the new form for new users. In addition, we want to add a mail alias to all of the mailboxes using the legacy format.
Can anyone suggest a relatively straight-forward way to add these aliases via code? Pulling the user's name details is not an issue, moreso just adding the alias to the mailbox. We're currently running exchange 2003 for most users, but are on the verge of a 2007 migration, and so have the odd user on 2007 also (the two servers are running side by side at present).
I've read that all exchange 2007 management should be done using the 2007 tools and not active directory as was previously the case, so can all of this be performed via the exchange 2007 APIs, even for 2003 "legacy mailboxes" (as termed in exchange)?
Basically I'm just looking for a good direction to go here; I've never really done any coding for exchange. Thanks!
Here's a MS KB that describes modifying the alias through extended MAPI. It looks like you'll need the Exchange Developers Kit to do this.
http://support.microsoft.com/kb/183249
I'm posting this after the question was answered, but is there any reason you didn't just use the recipient policies?
In the end I found Powershell was by far the easieast way to go. Here is a skeleton of the script I ended up using showing how to add an additional address to each mailbox:
$mailboxes = get-mailbox | sort Name
foreach($mailbox in $mailboxes)
{
...
# Logic for working out the new address
...
$mailbox.EmailAddresses += $newAddress
$mailbox | set-mailbox
}
And for completeness, this script was run on the new Exchange 2007 server. My initial concern with adding the addresses to mailboxes residing on the older 2003 server was a non-issue; the legacy mailboxes were updated too.
Related
i'm quite new to Logic Apps. I got the task to make an auto reply function within Logic Apps that integrates with Exchange Online. Now I already performed this task using Outlook, but I have to be able to apply it to multiple mailboxes or even the entire company using Exchange. I'm about to get access to the Exchange Admin Center soon, but I don't really know how to start due to the fact that there is no simple way to make a connection to Exchange using Logic Apps. After some research, I think it's necessary for me to somehow make use of a REST API (I also read about the use of Exchange Web Services) to get the information I need, but my knowledge about this is quite small. I guess I'm gonna have to use a program like Postman to request information, so that I can start creating Custom Connectors to Exchange. If anybody has some understanding about this, feel free to reply and help me out! I will forever be gratefull!
There are several different approaches you could take to this if you (or probably they in your case) want your logic app to do all the work then you should use the Graph API rather then EWS (while its possible because its older API you'll loose marks on your assignment) have a look at http://martink.me/articles/using-microsoft-graph-in-logic-apps which covers the basics of what to do. To Get access to mailboxes tenant wide then you need to assigned Application Permission and get certificate (and store that in the KeyVault on Azure etc).
You can do this using Inbox Rules https://learn.microsoft.com/en-us/graph/api/mailfolder-post-messagerules?view=graph-rest-1.0&tabs=http and the Exchange Server will do all the work when it comes to doing the Auto-response (and has loop detection logic already) and your logic app then just need to do the Creation and management of the Rules.
But I would suggest you clarify with the person who assigned you the task whether they want the logic app to do the response (eg using the Graph API) or if its okay for the Exchange Server to do this for then (which should be more reliable).
You can also create Rules via the Exchange Admin Center and you could probably also through in Power Automate into the mix to do Autoresponse's so I'd clarify what they want so you don't waste time building something they don't want.
I have an old Exchange 2003 server that we connected to via WebDAV. We had one app using it and in it we were setting some custom properties to appointments in the DAV namespace like DAV:OrderId, where OrderId is the name of the custom property.
Now we're going to move the mailbox to Exchange 2010 to start with and since there's no WebDAV support for it, I can't find a way how to read that custom property with Managed EWS (Exchange Web Services).
I tried getting them with searching through
DefaultExtendedPropertySet.Common
and
DefaultExtendedPropertySet.PublicStrings
collections, but of course they're not there.
Our app kind of needs those properties to work.
Anyone have any ideas?
Sorry I can't be more specific here, but I've not wanted to grab any custom properties off Exchange items. However, there is a way to get MAPI props in EWS, and there may be a way to dig out the custom props as well. It's worth a look. Start here, and let us know if you work it out!
Well I found what I was doing wrong.
By using MFCMapi on the Exchange 2003 server I was able to see that the actual full property name is "DAV:OrderId" and not just "OrderId". It's namespace is DefaultExtendedPropertySet.PublicStrings. So just use those two pieces of information when querying with EWS and you're good to go.
I would like to programmatically be able to access all the emails stored in an exchange server in order to do some text analysis on those emails. How would I go about this, assuming I had all the necessary permissions and direct access to the server?
My gut says you should use eDiscovery tools built into Exchange, but I'm not entirely sure that will accomplish what you want. eDiscovery does what it was designed to do pretty well, but that's entirely focused around finding emails in a date range or via keyword.
I'm looking to write an automated monitor script to programmatically retrieve information from another user's Exchange 2003 inbox. I have working C++ code to log into MAPI and connect to my own inbox. I can also use the Control Panel->Mail applet to configure another user's mailbox into my profile, and my code can access that way. However, this was done on my desktop with Outlook installed, which provides a richer mail profile editor.
Since this will run on a server, I'd prefer not to install Outlook at all. Instead, I can install the MAPI client. I then create a simple MAPI app that pops up the mail profile wizard using MAPILogonEx() with the MAPI_LOGON_UI flag. However, the basic MAPI client doesn't have the features to configure another user's mailbox. As a requirement, I can only run this script as the service account of the monitoring application, so I cannot tell it to run as the account whose mailbox I want.
Is it still possible to connect to another user's mailbox (assuming permissions are already granted) using the basic MAPI client? Or is it absolutely necessary to install Outlook for this functionality?
I would strongly recommend using the Microsoft Exchange MAPI Client (as you have linked). It is engineered to be far more robust than the Outlook version of these libraries. You should find the API no different between Outlook and Exchange Server with respect to Extended MAPI.
You will need to use Extended MAPI (as described by Cain T S Random) to open other mail stores, and of course your application will need to be logged in as the Windows user with appropriate permissions on the Exchange server.
I see... I'm not sure how to do that explicitly; that's usually a side effect of calling CreateStoreEntryID with the wrong flags. What's you're looking to do is probably:
Get an IID_IExchangeManageStore from your default message store
Call CreateStoreEntryID
Then open that store by the entry ID
LPEXCHANGEMANAGESTORE mapiObject = NULL;
store->QueryInterface( IID_IExchangeManageStore, (LPVOID *) &mapiObject);
mapiObject->CreateStoreEntryID( server, mailbox, OPENSTORE_TAKE_OWNERSHIP |
OPENSTORE_USE_ADMIN_PRIVILEGE, &len, &buffer);
//Call OpenEntry on the entry id
If you want a more detailed example, search the source of the MFC MAPI project for CreateStoreEntryID. If you have other questions, the best place to get them answered is the microsoft.public.win32.programmer.messaging newsgroup.
Have you looked into ConfigureMsgService? I believe that works with Exchange MAPI, or are you saying you tried that and it didn't work?
Anyone know how to do this without using a third party program? If there no way to do it with a add-on someone can recommend one?
EDIT: I need to add this in the server so all users have the same signature.
Thanks
You need to create your own exchange message sink to do this. Here's a classic VB example from MS KB:
http://support.microsoft.com/kb/317327
and a VB Script one:
http://support.microsoft.com/kb/317680
And lots of goodness from MSDN about Exchange 2003 Transport Event Sinks:
http://msdn.microsoft.com/en-us/library/ms526223(EXCHG.10).aspx
If you're running Exchange 2007 then you can use Transport Rules:
http://msexchangeteam.com/archive/2006/12/12/431879.aspx
http://www.msexchange.org/tutorials/Using-Transport-Rules-Creating-Disclaimers-Exchange-Server-2007.html
We used CodeTwo-s Exchange rules for a while on Exchange 2003.
However there is a known problem with it: if the messages stay in the queue for 2-3 minutes, the Exchange itself sends out the message without the footer. Most of the times it's not a problem, but we have something like 700 people in our organization. If there are a lot of emails and some of them contains attachments, then the virus scanner stops them for a while (MS Antigen).
Otherwise it's a perfect solution if you have a smaller group of users to manage.
From other point of view: our users like to have some kind of control over the signature. We generated them and put it to their Outlooks. They like it that they know and see that the signature is there and how it looks like.