I am investigating developing an app for Windows Phone 7 that requires access to email/calendar information from Exchange Server (read only).
The way I see it there are 2 options EWS or ActiveSync.
WP7 only supports Basic Authentication.
By default on Exchange server installations the EWS virtual directory has Basic Authentication disabled meaning a configuration change of Exchange Server to allow EWS to be used.
The ActiveSync protocol looks like it would take some time to get your head around and develop an implementation.
The questions are
1. How common is it for people to enable basic authentication for EWS? Is this something that most businesses are likely to not want to do?
How difficult is it to learn and use the ActiveSync protocol? Is it something that could be done in days, weeks or months?
1) To find out about the common configuration of EWS servers I'd spek to some sysadmins and ask them. Maybe try on https://serverfault.com/
1) How difficult something is to learn very much depends on the skills and experience of the person learning and the teaching resources available. This is a non-trivial protocol so I wouldn't expect learning it to take days. There will also be a licensing cost of implementing Excahange ActiveSync which I suspect would make it an expensive option.
Option 3: Create your own web service that acts as a proxy to EWS and does the authentication for you. Ugly and a bit painful, but if your app is architected well, once WP7 supports better authentication, switching to directly hit EWS should be pretty simple.
ActiveSync is painful and does not support everything that EWS supports. I would recommend going the EWS route if you have that option.
If your going to use ActiveSync, think again... it uses wbxml and you would need to create your own API for doing calls - this means crating tokenized blobs which must be 100% perfect and account for all aspects of whatever type of messaging items you are going against or will risk creating bad items or even poison ones. The devistation caused by bad EAS calls could well exceed your customer base... so, you need to be very careful. Also, while the specs are public, it needs an very expensive license. If you license, you would need to get a support contract with a specific schedule in order to get develper support. With a team of developers, it will likely take 3-5 or so years to do a full implementation client side and work out most of the bugs. So, as far as the skills in email development, you and your other developers would need to be pretty hard-core. There may be third party APIs which wrap EAS calls... however, you should be sure that they are licensed and that that the license would cover your development - so, you would need to research those on your own.
EWS has more features and is far, far easier to use and is what is suggested... further, there is no special licensing, etc.
Using a proxy web service+Exchange Managed APIs so that WP7 can go against Exchange without writting a ton of code:
http://www.telerik.com/products/windows-phone/getting-started/exchange-client.aspx
... can also use this approach to use NTLM.
Before considering EAS...
http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx
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 seen this question asked several times but the answers have so far been very robotic and disappointing:
What is the difference between EWS vs EAS?
Now, most sites give the following: "One is a protocol for mobile devices, the other is a web service." Well, no shit. Here's the real question:
What is stopping someone from setting up a descent library for EWS that any mobile app or OS could use instead of paying MS a per-user license fee for ActiveSync? Is EWS too expensive, since it's SOAPy instead of RESTful? Is ActiveSync doing more of the heavy lifting in terms of caching and general logic? Does EAS have some feature that EWS doesn't have (shared calendars or some such?) Is it really just a matter of mobile OSs wanting to ensure that Exchange 03 is supported?
I'm sure they each have their finer points that make them distinct, but the question that I think most people are getting at when this question gets asked is "Why should I pay for EAS if EWS can do the same thing and more if I'm willing to write the client side myself?"
Most organizations will license EAS because one or more of the following is true for them:
They want to allow existing mobile devices (iOS, Android, etc) to access their services without requiring new software to be installed on them (EAS is supported on lots of devices). Zimbra and Kerio do this, for example.
They can't use EWS as a client protocol to access their Exchange services, but EAS is available.
They want to operate in a low-bandwidth environment and can't afford the weighty overhead of SOAP within EWS compared to the compressed WBXML of EAS.
I'd wager that #1 makes up the vast majority of them.
Aside: EAS is not RESTful. Everything goes over POST, there's no hypermedia or ability for the client to do content negotiation. It's basically session-oriented RPC, using WBXML as an encoding format and HTTP as a transmission protocol.
I have a desktop application which uses flat files (some xml and small pictures) as data. I want this data to be available on other PCs which have the desktop application installed and usable by a smartphone client (WP7 at the moment) as well.
The user should have it very easy to synchronize this data. He should be able to use accounts he already possesses (Live-Login, Googlemail, Facebook,...).
I thought about using Azure Blob Storage to save the data in Azure, the Sync Framework to perform the actual synchronization and the Access Control Service to handle authentication.
I have not used any of this technologies before so any advice would be great but I'm searching foremost for errors or shortcomings in this strategy I don't see yet. Is this approach viable at all?
Windows Azure is basically a virtualized datacentre. It is elaborate and complicated and is pitched at corporations who don't want to own their server infrastructure or hardware.
If I understand correctly, what you want is a cloud fileserver, not a whole LAN. Windows SkyDrive fulfils this requirement nicely and offers 25GB of storage per member with no charge for membership.
About Hotmail and Windows Live People often confuse Hotmail and
Windows Live, because when you set up a Hotmail account it uses
Windows Live for authentication and therefore you end up with a
Windows Live account and all the associated facilities, including
SkyDrive. However, it is entirely possible to set up a Windows Live
account using any email address as the username.
If you do this, it is important to be aware that the Windows Live
password associated with a given email address is completely
independent of the password required by the mail server that hosts
mail for the account. This can cause a great deal of user confusion.
For Hotmail (or any other mail server that uses Windows Live for
authentication) they are guaranteed to be the same password.
There is no official Microsoft framework support for SkyDrive. There is an open source project called SkyDriveApiClient, but it only works with the full .NET framework. I tried porting it but the author was a bit of an architecture astronaut, and it is absolutely riddled with [Serializable] which is not available on WP7x.
The WP7 guys have said that the WP7 framework will probably include support for SkyDrive but not in Mango (WP7.1) and given that Microsoft's typical release cycle is 18 months and Mango has yet to hit the streets, I'd say it will be two years before you can count on intrinsic cloud file services for WP7.
Roll-your-own wouldn't be hard, WCF services are dead easy to use from WP7. But that's not really cloud since you have to provide and maintain the server infrastructure yourself. For this reason and given the MS timetable, I have put a great deal of effort into producing my own SkyDrive client for WP7. Core functionality is complete and I am now refactoring, improving robustness and adding performance enhancements like local cacheing of tokens (cookies, essentially). I don't intend to release it; I have a number of apps planned that depend on this functionality and it suits me fine that there is a substantial barrier to competition.
I didn't tell you that to tease you. My point is that I'm so sure SkyDrive is the right answer that I put a lot of work into making it happen.
Cloud file storage is a perfect fit for mobile devices.
Azure is not a good answer for the sort of phone apps individuals want because the data store isn't shared in a way that required indexing or supports high levels of concurrency
I can certainly think of corporate phone apps that would benefit from using SQL Server as storage
Azure can do file services but it represents an ongoing expense. Nobody's going to put up with that when Google and Microsoft both give away web based cloud storage.
I can personally attest that if you're determined, it is possible to use SkyDrive from WP7.
Cloud storage is the only way you're going to get programmatically accessible storage that's shared by your user's mobile device and his computer. One of the things I intend to do that depends on shared storage is write a Silverlight app that lets you prepare map routes with multiple waypoints on a desktop computer and a companion app that uses them on WP7.
The Windows Live team has released what they call support for WP7. They supply a sample project showing you how to instantiate a browser object and load their login pages and manipulate them to log in and use their javascript API to manipulate SkyDrive.
This has one big advantage: browser cookies and cached credentials. The disadvantages are obvious; technical shortcomings notwithstanding the Windows Live team seems to think the only thing people want to do with a phone is tag their photos and fiddle with social media.
I have finished my own libraries. They do not support most of the social media twaddle. I have treated SkyDrive as no more or less than a cloud file system, providing
Authenticate(username, password)
CreateFolder(folderpath[, blocking=false])
Delete(fileOrFolderPath[, blocking=false])
SaveString(filepath, value[, blocking=false])
LoadString(filepath)
I could handle binaries but Convert.ToBase64 makes this unnecessary and strings are convenient for XML. CreateFolder, Delete and SaveString are optionally blocking. LoadString is always blocking because it's a function that returns the loaded string. CreateFolder is recursive so you can create an entire path in one call (eg /folder1/folder2/folder3). Calling CreateFolder on a pre-existing path has no effect, and SaveString uses CreateFolder to ensure the path is valid, making it unnecessary to create a filepath in advance. Authenticate loads the file system (except file content) into memory eliminating server chatter. This is asynchronous and a FileSystemReady event announces when the file system is completely loaded. The model is maintained as you add and remove files and folders.
This was a lot of work and no one reponded to my attempt to make it an open source project so I'm not inclined to give the fruits of my labour away, but provided your plans don't compete with mine I could be persuaded to come to an arrangement.
My company is working on a project to develop a desktop and mobile email client that can connect to different mail servers with minimal configuration for users or server admins. We want to be able to support Exchange but I've realised after some research that there are a number of issues to think about. Our goal is to be able to connect to as many types of Exchange server as possible, so we need to choose a protocol, or protocols to implement that will allow that. It seems there are 3 different protocols in use - WebDAV for older 2000/2003/2007 servers, Exchange Web Services (EWS) for 2007/2010+ servers and ActiveSync which is supported by everything post 2003 (I think).
My question is, which do you think is the best approach for implementation?
-ActiveSync seems to have the most coverage but is the biggest pain to implement. Would a dual implementation of WebDAV + EWS provide the same coverage?
Also, if there are any Exchange Admins out there, which protocols tend to be enabled by default? If WebDAV/EWS are always turned off by default then maybe ActiveSync is the only option. It seems that as the iPhone and Android support ActiveSync it is most likely to be turned on, but what about the others?
Also, would be interesting to have statistics of what servers are currently in use - i.e. how many are still using 2003, have migrated to 2010 etc.
Would like to hear your opinions.
Cheers,
Kevin
If you are building an email client and targeting Exchange, I would recommend ActiveSync. The other protocols -- WebDAV and EWS -- were not intended for generic email clients. EWS, for example, does not support transactions or syncing, so if you have multiple clients you will have to deal with tons of race conditions on your own. WebDAV requires some funky limitations and is not always enabled. ActiveSync is relatively easy to write, it just requires getting a license from Microsoft, and it always works with Exchange.
If you just want to send and read email, however, don't overlook IMAP and POP3. You'll find the broadest support for those, even though are disabled in the newest installations.
About Versions:
2003 should be hard to find, as it is out of any Support.
A lot companies have skipped 2007 Version, so you should find a lot of 2010/2013 installations.
Although Exchange 2016 was released back in october, I assume, that there arent too much installations out there (2016 is more like a CU to 2013 :) )
The company where I work for (1800+ Employees) is looking to enhance the personal relationships between its employees, allow a better collaboration and communication between departments and make it easier for the HR department to identify skills, experience and interests among the personnel (ex: we have some colleagues with deep knowledge of SAP modules and products, but during concrete projects it results very difficult to identify them and integrate them). Therefore, they want to implement a social network for our intranet.
We are just looking for the basic features such as profiles, discussion boards and so on, so nothing fancy. I proposed Community Server but my boss said .Net and java are no-gos. He wants LAMP and is not interested in a web solution like Ning, because of privacy and security concerns. It does not matter if it is Open-Source or commercial software. But it should allow a complete layout customization and must also have access from the outside world.
So my question would be, is there something like Community Server running on a LAMP stack?
Thank you very much!
UPDATE: We already have a Facebook page and a group. But my boss wants some features not included in Facebook such as a tag cloud in each profile page displaying skills and relevant proyects; and a feature like the "neighborhoods" from Last.FM, where you can group people with similar skills and interests and there is also the confidentialy issue (discussions about projects, clients, etc). So, any ideas?
You should check out StatusNet. http://status.net/
It doesn't directly answer your question, but aren't you rather trying to reinvent the wheel?
Facebook has got Social Networking down and the likely hood is 95% of your 1800 employees already use it.
Why would you go to the effort of writing and supporting a product as well as asking your employees to update information about themselves in multiple places when you could just set up a Facebook Network.
The other point I would make is, why are you limiting yourself to one way of doing things right from the off. Perhaps a detailed analysis of which technologies best serve your purpose would be more appropriate.
I appreciate this doesn't answer you question, I just feel this is a good example of Corporations unwilling to embrace tools already out there, I suspect because they are scared of them.
I'm probably right in guess that you're company heavily monitors Facebook usage, which is why this also might be hard.
Try Open Atrium, a Drupal-based team server.
Some sort of facebook application would allow you to keep the data on a server that you manage, but still use facebook's existing features. Pretty certain that facebook uses PHP for its application framework.
I agree with MrEdmundo and would upvote him if I were registered. Dont fall victim to "It wasnt invented here" syndrome. I bet your boss is like "we need something like facebook".
If it makes you feel better... here is a little story:
I was trying to implement some sort of group chat so fellow employees could ask quick questions to eachother online without having to get up or if someone was on the phone, etc. However, the service I installed (some sort of jabber daemon, i forget which one) never really got used. The solution? Just install the facebook chat client because all the co-workers are already on facebook most the day anyways!
plus, the "screen name" is appropriate because it is our real names, not stuff like "Out Into Space", "theman", or "fly-mystikal-dj-69"
You might want to consider something like Drupal. It's technically a CMS, but it's extremely customizable, and there are a lot of modules available that provide social-networking-style features.
Use Office Messenger for communication. It's basically like MSN Messenger but run on the company's servers so they can monitor all traffic. To know who has expertise in what area, it can't be too hard to build your own simple CRUD application to record profiles of employees and have each profile tagged with key skills, that the employee has and build a search function to find the people with the skills you need at any given time.
You can create an application using the Facebook SDK (PHP, java or any other language) and moderate it so that only employees can use it. That way you can use the existing Facebook features and add the tag clouds and other stuff your boss wants.
I've not used it, but Dolphin might be worth downloading to try out.
elgg.org
LAMP easy to install and setup, looks like your requirements would all be easily satisfied by the official plugins that are available.
Another option: http://buddypress.org/