I want to run a script when an email is received on my exchange server. I really don't have a great direction on how to implement this. I've written my script in VB and tested it on outlook. I incorrectly assumed you can run a script from a rule in Exchange like you can in Outlook.
Any help would be greatly appreciated. Should I be using smtpreg.vbs or EWS or something completely different?
Exchange used to rely on event sinks for this kind of processing, but this is deprecated and not supported anymore in Exchange 2010; as the linked article says, the preferred way to handle events are now either developing a custom transport agent or using Exchange Web Services.
What you may be most interested in are EWS event notifications:
http://msdn.microsoft.com/en-us/library/aa579128(v=exchg.140).aspx
http://msdn.microsoft.com/en-us/library/bb204076(v=exchg.140).aspx
The last link provides some code samples, too.
As usual, since this is more of a developer-oriented question, StackOverflow is probably a better place to ask for detailed help.
Related
We'd like our clients to be able to, from our software, open documents and collaborate on them in the course approving them, then releasing them. We'd like to provide that using Office Online Server from a window within our software (using WOPI protocol). So if I understand correctly, we'd need our software to be able to specify the document, open it in the Office Online Server window/iframe and allow the collaboration to take place there. Then the client would save the document, and our software would take over from there. Can something like this be done?
From my research, #rocky (user:1332034) is the person that seems most likely to be able to answer these questions.
Yes, this is exactly what the WOPI protocol can do for you. The architecture, in your case, should look something like this:
The WopiHost.Discovery and WopiHost.Url can help you with generating the URLs. WopiHost.Core can help with the WOPI protocol communication.
Diagram link
I am working on an application that connects to numerous e-Mail services including Microsoft Exchange. Now that I've seen that there is an Outlook Web Access API, my simple question is:
Where do I get a sandbox (ideally free) to test my implementation on?
Do I really need to install all different Exchange versions, create accounts etc. with Outlook Web Access on top?
I don't have any Windows servers or licences. It's a web application running on Linux servers. Doesn't Microsoft have an Exchange sandbox or anything?
Many thanks in advance!
You might try an evaluation version from the Microsoft evalcenter here to test anything with and do an evaluation.
But just a short advise: There are multiple Exchange versions out there (Exchange 2010, 2013, 2016) with different Service Packs or Cumulative Updates. So checking only one version didn´t mean that your application will work with every exchange server. The best option I can think of is using IMAP on Exchange. This should be nearly identically on any Exchange Server while the Outlook Web Access (OWA) API might change from version to version.
However that depends on you solution and what it needs to perform.
Alternatively, you could get a trial O365 (Exchange Online) account and just run against whatever users or resources you have there. A 3-user license is maybe US$100 a year or thereabouts. Of course, this will mean you're running against the latest Exchange version, so the earlier ones would still need to be tested via eval versions.
As to the API, I'm really not sure about the OWA API, nor have I used IMAP. The "official" way to access Exchange is via Exchange Web Services or EWS. This comes in various flavors, can be used from Java, PHP, and other non-MS platforms, and provides a pretty robust and full-featured access into Exchange. My use of EWS has been limited to Windows/C#, so I can't vouch for the non-MS stuff, but it's been out for a while, and there is also a REST interface now--again no experience with that for me.
We have an enterprise MS Exchange server on the one hand and a different web-based time-management software on the other hand. In the latter the employees request vacation dates but these cannot be viewed by everyone.
So we would like to import the granted vacation dates as dates in outlook for every user, i.e. import it somehow in the Exchange server.
From the time-management software I can export Excel-Sheets month-wise, so I could read those programmatically and push that information into Exchange (e.g. via some C# program). However, I'm not in any way familiar with Exchange, and I don't know under what terms I should google this functionality.
Any hints to APIs or examples?
If you are targeting Office 365, use REST APIs. Take a look at http://dev.outlook.com for more info including Getting started.
If this is an on-premises Exchange 2007 or later server, use Exchange Web Services (EWS). Easiest way to do that is to use EWS Managed API.
For some time I have been looking at the possibility to integrate PowerShell as a scripting engine in SharePoint but I haven't found the right solution yet.
My main objective is to enable event triggers in e.g. a list to call and execute a PowerShell script (by filename) on the local server. This would give me a lot of flexibility compared to using an ordinary event handler written in visual studio, but the question is whether it is possible and whether I have overlooked some serious security issues?
Since each and every unique idea that I come up with in many years have already be invented by somebody else, I might have missed an existing product/project so any links to such projects will be appreciated, thanks
In the spirit of "already being invented by somebody else", check out http://www.codeplex.com/iLoveSharePoint for some very interesting uses of PowerShell inside SharePoint. Some great code samples and documentation. Haven't tried myself yet, but seems interesting.
I see what you're trying to achieve, but there's something that just doesn't "feel right" about a user indirectly running script code on your server.
The key difference is that the script can be run by anyone logging into the server. Event handlers can only be run by SharePoint. Strict validation of any inputs would be essential. You should also ensure the script is signed so tampered scripts won't execute.
Also, scripts by their nature aren't really designed for enterprise solutions. There is less opportunity for best practices such as good software architecture, design patterns, source control, code analysis, unit testing, and reuse of code. It's also messy/difficult to share code with a common code base that contains web parts, controls, entities, etc.
Finally, introducing PowerShell means another technology to be maintained in the mix we already have with SharePoint. This might be OK if you are comfortable with it.
Depending on how much customisation has already been done or is planned for the future some of the points above may not matter. Be sure to think about how this idea would feel if implemented 6, 12 and 24 months down the track.
I need to figure out a way to build a hierarchy by Director->Manager->Employee from an exchange server. I have very limited knowledge of exchange, so does anyone have any ideas for me?
Thanks
The only thing that I can think of that may help here is the manager attribute in AD.
To build a proper hierarchy based upon the manager settings may require some coding.
I can't understand what you are trying to achieve in Exchange.