Browsed by
Month: January 2017

What the heck is the GraphAPI and why should I care?

What the heck is the GraphAPI and why should I care?

So recently I have been spending time learning about the new Preview Intune Portal which is moving over to the Ibiza Azure Portal. As part of this migration from the existing Silverlight Intune portal to the new Ibiza portal Microsoft is working on exposing a vast amount of information (if not all) for your Intune Subscription via the GraphAPI. I’m going to quote from the Microsoft Graph website here the GraphAPI is “One endpoint to rule them all”, I’m sure there is a joke about rings and volcano’s that could be put in here.
But in all seriousness GraphAPI is well on it’s way to living up to that tag line, today as i write this there is already a vast amount of objects from the Office world which are already available to interrogate for example you can do a simple “Get” request on: https://graph.microsoft.com/v1.0/me you will be able to see a JSON response. I’m sure you have just clicked on the link and you got a JSON reply looking something like this:
{
“error”: {
“code”: “InvalidAuthenticationToken”,
“message”: “Bearer access token is empty.”,
“innerError”: {
“request-id”: “c6a2dcfe-4ee6-489a-9de3-a5573c6e2576”,
“date”: “2017-01-27T03:35:07”
}
}
}

So as you might have guessed by now it’s not completely straight forward to interrogate the GraphAPI, this is actually a really good thing as you need to provide an access token to be able to query the data from GraphAPI. To test a query you can use the Graph Explorer which you can find here: https://graph.microsoft.io/en-us/graph-explorer
By default it will be signed in with a “Demo Tenant” where you can test out the API calls, but once you sign in you can interrogate your own data you will be prompted to allow the Group Explorer access to your data during logon so you know what type of items which the GraphAPI has access too.
If we run the same link as we previously ran in the GraphAPI you will get a JSON reply which looks something like this:
{
“@odata.context”: “https://graph.microsoft.com/v1.0/$metadata#users/$entity”,
“id”: “2f2916e5-953c-4c5d-9f52-bd5db8131d49”,
“businessPhones”: [],
“displayName”: “Steven Hosking”,
“givenName”: “Steven”,
“jobTitle”: null,
“mail”: “steve@AusIgnite2017DEMO.onmicrosoft.com”,
“mobilePhone”: null,
“officeLocation”: null,
“preferredLanguage”: “en-AU”,
“surname”: “Hosking”,
“userPrincipalName”: “steve@AusIgnite2017DEMO.onmicrosoft.com”
}

As you can see GraphAPI is quite secure, in that you can’t just randomly query the GraphAPI objects from another company without a Access Token. In this demo the Graph Explorer handles the process of obtaining access to your Subscription be it Intune, Office 365, or Azure Active Directory.
It’s also worth noting as of today to access the Intune sections of the API you need to change the v1.0 to Beta in the URL’s, in saying that not all Intune subscriptions have currently been migrated to the Ibiza Portal which enables the GraphAPI so you might not be able to test this, to find more information regarding the Intune GraphAPI have a look here as it will be continually updated during the roll of the Ibiza Portal support.

In future blog posts I will explain the process to query the GraphAPI with PowerShell.

Good Luck

Steve

Rerouting PowerShell text Streams to Application Insights

Rerouting PowerShell text Streams to Application Insights

So recently I have been working on a solution where we have blended scripting languages being PowerShell and C#, and found logging to be a little painful in the sense that if you use a single file to track the process which would be ideal there is a good chance there will be write locks and etc. between the scripts. With that in mind I started digging deep into Application Insights for the C# solution, and tracking down the processes for using Application Insights in PowerShell, the process for both of the languages seem pretty straight forward, load the DLL add your instrument key from your Application Insights subscription, then start sending messages up to the service.

Great so we have a logging solution which will go across both languages with ease now the next step is to implement the logging, for a web site written in C# this is a matter of installing the nuget package, and configure the solution to use the correct subscription, it will then capture the cool things like time it takes for page loads and etc. using the default configuration, all in all about 20-30 minutes to capture basic audit information.

For PowerShell it’s not so straight forward as you need explicitly state each time you want to log something, so we need to update the script, this is where i started balking as the script in question were a mess of over 2000 lines over 2 different files, but i found that if i use the -Verbose switch on the top-level function it will return a detailed step by step of whats being completed, and with the standard PowerShell redirection “*>&1” it will pipe it out to a text file easily, great we are now back at writing it into a log file not application insights.

This got me thinking can i pipe the text streams from the function into another function? The simple answer is yes it is possible, great i can just push the text directly up to Application Insights fantastic, by default I get a GMT time stamp, and i know where it was invoked from.

But a text message out of context is as about as useful as disconnected log files, here is where i found out something about these messages which I hadn’t realized, that they are actually objects which contain the line where the script has thrown the message from, along with the PS1 file which it was invoked from. Great this makes it super easy, well not quite each of the different streams are a different object unique to the object type, with the exception of Write-Output which is actually a “System.String” object type which makes it hard to capture (not impossible tho).

So with the above in mind here is a sample script which shows the process of redirecting all of the different text stream’s from a function up to Application Insights, I also included a switch to have the results print back on the screen if it is still required to action it.

So i hear you think great you’re using Application Insights but i don’t have access to that, well here is the cool part you can change out the lines which refer to Application Insights for your favorite logging tool, or even have a default action which will stop the script if there is an exception detected in the script.

Good Luck