We currently have a web application which requires manual intervention in order to initiate the transfer of data from Azure Active Directory (via the Microsoft Graph API) to a local SQL Server database instance for archival and reporting purposes. This manual process is often run multiple times per day.
Our goal is to automate this data transfer process through use of a Windows service application; however, we have encountered an issue with instantiation of the Microsoft Graph client. The vast majority of the documentation available seems to presume the use of Microsoft Graph with a user interface (which the service app doesn't employ). Methods which work quite nicely with the typical MVC-based C# web application don't sit well within the more limited confines of a Windows service app.
Is this type of automation possible? If so, is there any sort of documentation available regarding the use of Microsoft Graph within a Windows service app?
Any assistance is greatly appreciated.
There is a documentation where is described how to call Graph API from a background service or daemon app without any user interaction. The same way will work for Windows service.
Documentation
Get access without a user
Related
In our experience with other APIs there is usually a test/private mode and then after the app is approved it can go into live/public mode.
After we create an application based on Microsoft Graph / Outlook REST, what is the process to get the application live/public available for use by our customers and how long does it take? Or is it already live?
Your question isn't really specific, so I'll just answer the general question.
Everybody can create an application for the Microsoft cloud. There isn't a test environment, so every application is live the moment you create it (and switch on multi-tenant). It is always up to the user (or tenant admin) to grant your application access!
Microsoft does however offer various ways to get your application under the attention of a much larger audience. And to get your application in such a marketplace they have various review/test/... processes in place.
I am interested in learning to use the Smartsheets API. In the past I created workflows in Google Apps Script, which has a built in IDE that houses the script. Does Smartsheets have something similar? If not, where is a common place to keep your code and have it react to webhooks/events?
Regards,
Shawn
The API is just a way to communicate between your application and Smartsheet - there is no hosting for your executable code. Smartsheet provides a number of SDKs to help make the calls easier to perform, but in theory you could use any language to make the REST commands. So, pretty much any service that allows executable code would work, such as Amazon AWS, Google Cloud, Microsoft Azure, or others. Here's a brief comparison of services.
You can start developing on your own computer before you worry about cloud deployment. See the getting started guide and samples here: https://github.com/smartsheet-platform/getting-started
If you really need to respond to webhooks, your code will have to run somewhere that accepts incoming HTTP calls from the Internet without being blocked by a firewall. This could be in your data center, any of cloud services, or via a tunnel such as https://ngrok.com/
I was wondering if its possible to create a powershell script to log into a specific outlook mail box and than add the script to the scheduled task so that no user has to be logged on.
If you need to open an arbitrary Exchange mailbox, you can either
Use Outlook Object Model (which cannot be used in a service, such as the Scheduler) to log to a predefined profile (Namespace.Logon) and call Namespace.GetSharedDefaultFolder. If the set of mailboxes is always the same, you can add these static mailboxes to the profile (open them as delegate mailboxes) and access them programmatically using the Namespace.Stores collection. Again, Outlook should not be used in a service/scheduler.
Exchange Web Services - it is HTTP based, so you can use it from a service
Graph - just like EWS, it is HTTP based, so you can use it from a service
Extended MAPI (C++ or Delphi only). native API used by Outlook itself. It can be used in a service.
Redemption (I am its author - it wraps Extended MAPI and can be used in any language from a service). It lets you dynamically log to an Exchange mailbox using RDOSession.LogonExchangeMailbox / LogonExchangeHostedMailbox (no existing profile required). Other mailboxes can be opened using RDOSession.GetSharedMailbox.
Yes, you can log on to a specific user profile programmatically. The Logon method of the Namespace class logs the user on to MAPI, obtaining a MAPI session.
Be aware, Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. You can read more about that in the Considerations for server-side Automation of Office article.
Instead, you may consider using a low level API on which Outlook is built - Extended MAPI. Or use any third-party wrappers around that API.
I'm writing a mobile application, and this mobile application will be talking to a server in Azure to get data, and possibly push some too.
Now, I always had it in mind that I was going to write a simple RESTful web service that was going to deal with all this, and host it on Azure in a website - however, I've since discovered their Mobile Services, and I'm not entirely sure I understand what it's for.
Looking at it, it seems that it's about extracting away the code running on the server from you, and what you push to it, is what you get back? So it wouldn't be much use for me, as my web service is going to be returning data dependant on logic etc. However the ability for the Mobile Services to deal with push notifications directly is nice (how hard is it to use Azure Websites to send push notifications through mobile services?)
However, I wonder if I'm missing something? I'd rather not have to go re-invent the wheel as such, is Mobile Services will do what I need, especially as I'll be using Xamarin and there is a nice component to talk to Mobile Services...
Thanks
I am facing the same question: Should I use Azure Mobile Services or roll my own REST service. Below are some discoveries I have made so far.
With Azure Mobile Services there is a backend running a set of assemblies, which your code ultimately depends on. This is fine until you start using versions of other assemblies, which are not compatible with the versions Microsoft hosts. To me this is a major pain. This problem alone makes me question whether I want to use Azure Mobile Services. If you make your own REST service, I do not expect you to face these problems. See this link for details.
You should note that an Azure Mobile Services is tied to a single Azure region: If your Azure region fails, you need to manually migrate to another Azure region. This might not be a problem for your project. If you want to run in more than one region, I think it will be easier to roll your own REST service.
Regarding push notification, you could do that without using Mobile Service. See these links:
http://msdn.microsoft.com/library/azure/jj927170.aspx
http://weblogs.asp.net/scottgu/broadcast-push-notifications-to-millions-of-mobile-devices-using-windows-azure-notification-hubs
Auto-scaling is supported out-of-the-box in Azure Mobile Services. You would need to make your own scaling logic if you make your own REST service. You can scale VMs using Azure’s REST API, but it will be more work than using Mobile Services.
Authentication is supported in Azure Mobile Services. You would need to look into a separate framework to do this if you make your own REST service.
If you use Mobile Services you will probably create ASP.NET Web APIs through the Visual Studio wizards. There are examples and tutorials, which is great. However, even if you roll your own service, you could build on other frameworks. One example is ServiceStack, which I would strongly consider if you want to make your own REST service. I think ServiceStack could also help with authentication.
If you use Mobile Services you will tie yourself stronger to Azure. By rolling your own REST service it will probably be easier to move to another infrastructure later.
PowerShell Web Access allows you to run PowerShell cmdlets through a web browser. It shows a web based console window.
Is there any way to run cmdlets without typing them in to the console window? And is there any way to get the results back?
I'm envisaging an app that lets a non-technical user restart a print queue (for example) without having to know PowerShell. The app would display a list of print queues and then the user could select one and restart the queue. The app would essentially be a wrapper that takes care of the syntax and variables so that users don't need to know.
Is there a way to do that through PowerShell Web Access? Or is there some other way for a non Windows app to send arbitrary commands to a Windows server without reinventing the wheel?
Not with PowerShell Web Access**. That is designed for an interactive session.
There are a few ways you could do this. All examples are illustrative and may be outdated, insecure, etc.
Create an ASP.NET web application running C#. Run PowerShell in the C#. Use PowerShell remoting as needed. Example.
Create GUI applications using Windows Presentation Foundation or WinForms. Use PowerShell remoting as needed. Example.
Create a services with an API (e.g. REST) that PowerShell can hit.
** OK, I lied. Create a clunky solution that uses delegated, constrained endpoints accessed through PowerShell Web Access.
For each of the above solutions that uses PowerShell remoting, consider delegated and/or constrained endpoints. Example.
We have a web application that allows certain users to perform certain functions with certain parameters. Uses ASP.NET backed by C# with a set of predefined PowerShell scripts and configuration of who can do what stored in a SQL DB. For example...
Jane can restart application pool X on server Y.
John can restart service Z on server Q.
IT Support can unlock their own 'administrative' accounts from their standard accounts.
All of this can run from non-Windows computers. Some of it might be carefully exposed to allow use on Mobile devices : )
If you have the use cases, the small overhead of designing the system and writing the code behind it will pay off quite quickly.
Cheers!