 Even though Microsoft retired the MS600 exam and the associated Microsoft 365 Developer Certification in March 2023, you can still use the free self-paced resources that Microsoft provided to learn how to build solutions with Microsoft Graph. In this video, I'm giving you my entire guide that walks you through these free resources, including lectures, hands-on labs, and videos. Hi, I'm Andrew Coll, and if you're new here, be sure to hit that subscribe button to stay up to date on all my videos for web and cloud developers on Microsoft 365 and related topics. And while you're at it, make sure you subscribe to my newsletter to get insights and the latest news in the world of Microsoft 365 for web and cloud developers. I've got a link to it here in the one in the description below. Before we get started with this, I want to set some context on what this video is going to cover. And while this only takes a moment if you're familiar with the history of my MS600 exam prep course, feel free to use the chapter links in the description below to jump ahead to the start of this guide for self-paced learning about building solutions using the Microsoft Graph. I created an exam prep course for the MS600 exam building applications and solutions with Microsoft 365 core services that hundreds of developers had used to prepare for and pass the exam. Microsoft used the exam to measure a developer's knowledge around a few Microsoft 365 workflows, things like SharePoint, Microsoft Teams, Azure AD, Microsoft Graph, and Office Add-Ins. But when Microsoft retired the exam in March 2023, I was left with this course that served as a guide for all those free self-paced study resources that developers could use to prepare for the exam. I can't sell that. No one could buy it would buy that course or more importantly, I can in good conscience sell it because the exam doesn't exist anymore. But here's the thing, the course content is all still valid. It's a self-paced guide on how to learn various things, like what you need to know to be a qualified developer building solutions using the Microsoft Graph. So I've decided to release the chapters for each of the different workloads here on my channel. That's what you're about to watch. Note that there are parts of the video where I refer to the exam. Just know that the exam I'm referring to the MS600 exam. That's retired at this point and it's no longer available to take. Also throughout this video I'm going to reference a lot of online resources like documentation, training modules, videos, hands-on labs. The links are all in the video, but I've also compiled them in a single downloadable PDF and you can get this from the link in the description below the video. It's all on my site. Okay, enough with the explanation out of the way, let's dive into learning about the free self-paced resources for learning about building solutions using the Microsoft Graph. Microsoft Graph is a huge topic as it's just an API. Microsoft Graph provides a unified programmability model that developers can leverage to access nearly all data within Microsoft 365, Windows 10, enterprise mobility and security. In this lesson we're going to look at some development patterns and practices that you need to be familiar with, not just for the MS600 exam, but these are things that you should apply in all of your applications that leverage Microsoft Graph. Microsoft likes to start the discussion with query parameters, but I think it's best to start not with the how, rather let's start with the why. The entire point of this lesson is why you should care about incorporating good practices and patterns into your applications when leveraging Microsoft Graph. And for that I like to start with the pain that you can avoid by doing so. That starts with a discussion around throttling. Microsoft Graph is a highly used API that has become mission critical. Microsoft uses it, ISVs use it for their products and you can use it in your custom apps. In order to keep it up and running and responsive for those that need it, it has some built-in protections to ensure that a bad actor doesn't overload it and create some issue for other users. This protection mechanism is referred to as throttling and throttling is the process of monitoring requests from one source over a period of time. If certain limits are exceeded by that source over a period of time, Microsoft Graph will reject the request and return a result that effectively is telling the requester, your requests have been determined to be negatively impacting the service that can impact the health, responsiveness and reliability of the service for others. So how do you know you've been throttled? Microsoft Graph will respond with an HTTP status code 429 and usually a value in the retry after HTTP header value. An application shouldn't repeat the request until that time has elapsed. So if you get throttled when you exceed the limits, how do you avoid those different limits? The exam is not going to test you on the specific limits because each endpoint has different numbers and that's because the endpoint is just a proxy to another API that's managed by some other team at Microsoft. If you want to see the specific limits, refer to the links in the lesson notes under this video for each of the different endpoints. But again, the exam is not going to test you on those different numbers. What you are tested on is how to avoid being throttled as well as how you should deal with it when it does happen. So let's first look at how you can avoid it and this can be done by following or avoiding a few different common patterns. First, the most common practice that triggers throttling responses is continuously polling Microsoft Graph for changes. The best ways to avoid this are to implement change notifications. And this is when you subscribe to a specific endpoint and tell Microsoft Graph to notify your endpoint via an HTTP post when things change. This keeps your application from constantly asking Microsoft Graph if things have changed. The other option is to use the Delta query and instead of asking Microsoft Graph for all the items that have been updated or added since a specific time, you issue initial request and then you submit a specially modified version of that same request for changes that have happened since the previous request was issued. Microsoft Graph will return only those items that have been added or updated since the initial request. And when you issue the third request, Microsoft Graph will only include those changes since the second request and so on and so forth. By combining Delta query and change notifications, you can dramatically limit the number of round trips that Microsoft Graph to Microsoft Graph and thus limiting the chances where your application is going to be throttled. The MS600 exam is going to test your knowledge on both change notifications and Delta query. So refer to the links in the lesson notes for documentation and Microsoft learning modules on these different topics, including hands on labs. Now, as much as you should try to avoid from being throttled, your application should assume that it will be throttled at some point. When this happens, you need to understand how to identify when that happens as well as how to address it. So first, your application can identify when it's being throttled by receiving an HTTP 429 status code. From Microsoft Graph, when you issue your request to Microsoft Graph. When that happens, your coach should enter a process like a managed loop that will try to request after a certain amount of time elapses. But how long should you wait? Look at the retry after HTTP header when you get a 429. That's going to tell you the number of seconds to wait before resubmitting the request. If you submit your request before that time elapses, you're going to get another 429 with a longer retry after duration. So make sure you respect that value. However, some endpoints don't include a retry after header. And in those cases, you should implement a fallback exponential back off retry process. And so, for instance, let's say that you retry the request after two seconds. If you get another 429, you should repeat that only after four seconds. If you get it again, wait eight seconds to make that request and then so on and so forth. Now, of course, there's a point where you don't want to just double keep doubling the time because it's going to be unreasonable for your application or for your end users experience. These patterns to handle throttling are the ones recommended by Microsoft 365 and they're covered on the MS 600 exam. They are so important to Microsoft and so many people have hit them that they've included them on the exam. So you need to understand these patterns and how to address them. So you should be familiar with how to identify a throttling response request and how to handle it both with a retry after header or with an exponential back off strategy. One more note on this. The SDKs or a lot of the SDKs actually implement this stuff for you. So that's one of the reasons that Microsoft does recommend that you use their SDKs and that may come up on the exam. But you really need to understand how to address these different issues as well. Okay, another optimization topic that addresses query performance is using various URL parameters or query parameters. These are supported by the different Microsoft Graph endpoints. They can be used not just for query performance, but also to help limit your query endpoints that could lead to throttling requests. These query parameters are used to limit the results returned by Microsoft Graph either by limiting the data or limiting the results set. And you should be familiar with all the different following patterns. Keep in mind not all endpoints support all parameters. And for instance, the context endpoint supports the dollar count argument, but it isn't supported on directory objects such as users and groups. The select parameter allows you to specify a common delimited list of properties that you want to receive in the response. The order by parameter enables developers to let data from Microsoft Graph get pre-sorted. And by default the data is coming back in ascending order, but you can add the descending keyword after the property to sort in descending order. And it also supports sorting by multiple fields by separating each field with a comma. The count parameter will return the number of items in the result set rather than the actual items that would have been returned by the query. The skip parameter enables you to skip the first number of results in the response. The top parameter enables you to limit the response to only include a specific number of records. So using count, skip, and top you can create like a paging implementation. The expand operator is used to expand the collection of items saving you from issuing additional requests. So you may have like say you want to get a user and then that user can have like documents that you can access off the user entity that comes back. You can actually pass in the expand and say instead of getting a user and then having to issue the request again for all that user's documents, you can say expand the document so I can get the user and all their documents. Another optimization option supported by Microsoft Graph is the use of the filter query parameter. That's going to allow developers to limit the size of the response by filtering on specific content. This should not be confused with the search capability. The syntax for filter query parameter follows the format of passing in a quality function with two parameters. The first parameter is the field to filter while the second parameter is the value that you should be filtering on. Now developers can also use the search query parameter to search for content against the people and message endpoints. Search cannot be combined with filter in order by operators. And then the batch operator, this is the last one we'll go through. This allows you to group multiple requests into a single request that Microsoft Graph will process individually and return a single response. Using batch can reduce the chatty aspect of an application, thus reducing the potential throttling issues that could arise with a chatty application. All of these parameters are covered in the Microsoft Graph documentation and in the Microsoft Learning Modules that I've included as references in the lesson notes under this video. If you're not familiar with all of them, you should study these and you should use the study materials that I've provided to learn more. Okay, so that wraps up the patterns and practices that you need to be familiar with when it comes to optimizing your queries for Microsoft Graph, as well as avoiding the throttling blockers that you can run into when calling Microsoft Graph. In this lesson, we're going to look at the user endpoint and the different aspects of working with user data when it comes to Microsoft Graph that you need to be familiar with for the MS600 exam. Now this lesson along with the next two are going to be much shorter than the previous lessons in this chapter. Like I said in the overview lesson for this chapter, this is just like an API walk. It's really just a list of the things you need to be familiar with rather than explaining much of how it works working with users. The first thing you need to be familiar with is how to get a user or a collection of users. You can obtain a list of users by submitting an HTTP GET to the user's endpoint. Or a specific user with one of two endpoints that are available to us, either use either the user's GUID, which is a GUID or their UPN, or just use the special me endpoint to get the currently signed in user. These requests will either return a single user or a collection of users depending on which one that you use. You can do the same thing with the .NET SDK. In this step, like all the Microsoft Graph tasks, start with obtaining an authenticated and configured Microsoft Graph client, represented as a Graph Service client. Either get a list of all the users by submitting an async request, or just get the currently signed in user, or you can get a specific user by passing in their ID into the user's collection. Another common request that you should know for the MS600 exam is how to work with profile photos. Profile photos are interesting because there are two aspects to them. There's the metadata about the image and the file itself. The metadata contains things like the type of media, such as the GIF or JPEG, and the dimensions of the specific photo, as well as the ETag used to determine when it was actually changed. This data is returned by the photo endpoint. You can also get this by using the photo property on a user object in the .NET SDK. When you want to work with the actual file, you need to use the $value endpoint on the actual file. This will return a binary stream that you can work with, and you can use the content property on the photo object to get the binary data for the image. The Microsoft learning module on working with user data, specifically units 4 and 5, are dedicated to explaining working with photos and include a hands-on lab if you need to have a little bit more practice. The last aspect of working with users that you need to be familiar with is making changes, including creating, updating, and deleting users. To create a user with the REST API, you're going to first create a JSON representation of that user and submit it using an HTTP post to the user's endpoint. This includes things like their display name, their alias, as indicated by the mail nickname, and their password profile detail that allows you to set the password as well as a flag, indicating that they have to reset it when they sign in. To create a user using the .NET SDK, you're first going to create a user object and then submit it using the addAsync method, passing in the user object. Notice this code contains many of the same properties the REST API sample on the previous slide contained. Now updating and deleting users is done in a very similar way, except that when you use the REST API, you'll use the HTTP patch verb when you're updating things, and the delete verb when you're deleting items. For the .NET SDK, instead of using the addAsync method, you'll use the updateAsync method when you're updating a user and the deleteAsync method when you're deleting a user. The Microsoft Graph Documentation links and Microsoft Learning module about working with user data cover everything you need to know related to this endpoint. So, use those to practice if you aren't familiar with any of the topics that I've covered in this lesson. That wraps up the user endpoint in working with user data when it comes to the Microsoft Graph. In this lesson, we're going to look at the files endpoint and the different aspects of it working with files when it comes to the Microsoft Graph that you need to be familiar with for the MS600 exam. Let's start by first looking at how to access files using Microsoft Graph. When you work with files, you're really working with files in OneDrive. This includes files that are really in OneDrive and those that are SharePoint and SharePoint document libraries. And while Microsoft Graph does enable apps to get files from both OneDrive for business and OneDrive consumer, the exam only focuses on OneDrive for business due to the focus on Microsoft 365. Files aren't as easy to work with as users and contacts and calendar items and groups or other items, at least in my opinion. So, let's take a minute to make sure that you have a grasp on these different things. There are two types of resources that you'll use to access files and both of these are directly related to OneDrive. A drive object represents a logical container of files like a document library in SharePoint or a user's OneDrive. A drive item represents an item within the drive object like a document, a photo, a video or a file or a folder. These two resources expose data in the following ways. There are properties such as ID, name and name that expose simple values as strings, numbers and booleans. Facets such as file and photo expose complex values. The presence of a facet like a file or a folder indicate behaviors and properties of the drive item. And then references such as children and thumbnails point to other resource collections. Now access the currently user signed in of users OneDrive using the graph that Microsoft.com slash v1.zero slash me slash drive endpoint. This endpoint will return the details about the users OneDrive including the date that it was created, last modified order information and what type of OneDrive it is, if it's OneDrive for business or OneDrive consumer. To access the contents of the root of the user's OneDrive you use the slash root endpoint. And from there you can get access to the user's files and subfolders and all the content within those different folders. Now when you're working with the .NET SDK you can access the user's OneDrive with the Drive property on the user object and then use the root property to get access to all the contents within that root folder. Now Microsoft Graph isn't limited to just accessing the current user's OneDrive. Developers can also use Microsoft Graph and enable the signed in user to access another user's OneDrive. That is provided they have permissions to do it. And this is done using the Drive endpoint from the user object. And this is referenced as a facet as I described previously. So to access the same pattern you can also access the OneDrive for a particular group by specifying the groups ID or you can also access the default document library in a SharePoint site. Microsoft Graph doesn't just give you access to files but it also supports downloading files from OneDrive. And this is done by getting a reference to the document and then reading a memory stream to disk. Uploading files to OneDrive using the REST API is another common task that you need to know for the MS600 exam. And this topic includes uploading small files such as those less than four megs in size and much larger files. So uploading small files that's actually pretty simple. To upload a file using the REST API you submit an HTTP put to the endpoint where you want the content to go including the file name and finish it with the content endpoint. And then you include the content of the file in the body. Updating a file is just as easy to repeat the process except you point to the URL of the file that you want to overwrite. Uploading a file using Microsoft Graph the Microsoft Graph.NET SDK follows a similar pattern. You have to read the contents into a memory stream and then use the put async method to upload the file. Now uploading large files to OneDrive requires a little bit more work. So a large file constitutes anything greater than four megabytes in size that will go all the way up to the maximum supported size by your OneDrive. Microsoft Graph supports pausing an upload as well as resuming a previously started upload and this is handled using a concept of a session. So what you have to do first is you have to first create a session by submitting an HTTP post request to the create upload session endpoint. That's going to provide a URL and a response to upload within a specific period of time. Now when you upload the file you need to follow the same pattern as uploading a small file except that you need to include how many bytes you're uploading as well as which range you're uploading. So you need to tell OneDrive here's a bunch of bytes and then here's where it goes in that file. In the following example notice that we're uploading 26 bytes as indicated by the content length HTTP header value but this only represents bytes 0-25 of a 128 byte file as indicated by the content range header value. The MicrosoftGraph.net SDK also supports large file uploads refer to the documentation and associated Microsoft learning module that explains the details of the process including a hands-on lab working with the large file upload task object. Now the last thing that I want to touch on are file insights. Insights are relationships that are calculated using advanced analytics and machine learning to show the relationships between users and files. And there are three different types of relationships that are exposed by Microsoft Graph. There's the trending endpoint that returns documents from OneDrive and SharePoint sites that are trending around a specific user. The used endpoint that returns documents viewed and modified by a user. This includes documents this includes documents the user used in OneDrive for business, SharePoint and opened as email attachments and as link attachments from sources like Box, Dropbox and Google Drive. The shared endpoint returns documents shared with a user. Documents can be shared as email attachments or as OneDrive for business links sent in emails. All these relationships are available using these slash insights endpoint off a user entity. Now the request returns a collection of JSON objects represented by two types of objects. The resource visualization object contains properties such as title and preview image URL and the resource reference object contains the ID, URL and the media type of the file that's referenced. The Microsoft Graph documentation links and Microsoft Learning module about working with files cover everything you need to know related to this endpoint. So to use those to practice, use those to practice if you aren't familiar with any of the topics I covered in this lesson. We're going to look at the teamwork endpoint and the different aspects of working with Microsoft Teams teams when it comes to the Microsoft Graph. You need to be familiar with this for the MS600 exam. Now this lesson was formally about Office 365 groups but groups are the underpinning of Microsoft Teams teams in Microsoft 365. And in the big August 2022 update, Microsoft pivoted and made what looked like a major change to the exam but in reality it was really minor and really just minor rewarding changes to this section. Mostly because they just swapped out the words groups for teams and there's been some updates to the API that are instead of having to go through groups, we actually can work straight with a Teams endpoint. From the Microsoft Graph, the endpoint that deals with the Microsoft Teams is referred to as the teamwork endpoint. But there's a lot of stuff that deals with Microsoft 365 and Office 365 groups as those are the artifacts that are the behind the scenes aspect of every team in Microsoft Teams. Throughout this lesson you're going to hear me refer to groups in a lot of different places. That's just synonymous with teams. Just be aware that you're going to need to be familiar with both groups and teams in Microsoft Graph to manage the life cycle of a team. Now there are two types of groups that Microsoft Graph is going to support. Office 365 groups and security groups. Office 365 groups enable people to collaborate on a project or a team and the members within a group share resources such as outlook conversations in a calendar, SharePoint files, a OneNote notebook, a SharePoint team site, planner plans and in-tune device management capabilities. Now within Microsoft Graph these groups are referred to as unified groups. Now unlike Office 365 groups a security group is used to control access to resources. Apps can check if a user is a member of a security group to determine if they can access specific resources within that app. Another capability of a security group is that while they can contain users like Office 365 groups security groups can also contain other security groups and this allows admins the added flexibility in determining users who can access secured resources. Another thing that you should be aware of for the MS600 exam are dynamic group memberships. A dynamic group membership that's supported by all groups involves creating a rule that automatically adds or removes members from a group based on properties. For example all the users in the marketing department they should have access to a group. Microsoft Graph supports managing dynamic membership rules through the group's properties membership rule and membership rule processing state. The first thing that you need to tackle is read or get information about a team and there are multiple things that you need to know on about how to prepare for the exam related to teams. Now while I'm only focusing on the REST API syntax refer to the included documentation and the associated Microsoft learning modules about groups and the teamwork endpoint for additional details and hands-on labs on working with both teams using both the Microsoft Graph.net SDK and the REST API. With all the groups within an organization you're going to use the groups endpoint. You're going to issue a call to the graph.microsoft.com slash v1 slash graph slash groups endpoint to get that and then you can filter using the resource provisioning option to find the string for a team. To get a specific team you're going to include the teams ID within the request so you'll go to the teams slash ID endpoint. To get a list of all the owners in a team you're going to use the slash members endpoint so you'll issue a request a get request to the graphs v1 endpoint slash teams slash whatever the idea of the team is slash members. Now the next batch of tasks that you're going to need to be familiar with is working with users and teams that they're associated with. You can also get a list of all the teams a user is a member of different from those that they're an owner of using the slash join teams endpoint. So you're going to go to the graphs v1 endpoint slash me slash join teams to get that list. Now another team related topic that you need to be familiar with is management of the team lifecycle. This includes creating updating and deleting a group as well as teamifying them. Yes, teamifying. That is a word. To create a group submit a complex JSON object with an HTTP post to the groups endpoint. The following sample that you see here is going to demonstrate how to do that using the .net SDK. And you can also create a team with the teams endpoint using the rest endpoint. And with that you're going to use an HTTP put to the groups slash ID slash team endpoint and pass in the JSON object that you see here. Now updating a team is as simple as submitting an HTTP patch to the teams endpoint using the rest API. You're going to issue the HTTP patch to the v1 slash teams slash ID endpoint and then pass in a JSON object as part of the body of the payload. You can also do this using the update async method on the .net SDK once you have a reference to that team. As you can see here from the code that I have listed. Now deleting a team is as simple as submitting an HTTP delete to the teams endpoint using the rest API. So you're going to go to the graphs v1 endpoint slash groups slash ID to issue that delete command to delete it. Or you can use the delete async method on the .net SDK once you have a reference to that team. Now another life cycle aspect of groups and teams that you need to be familiar with is the concept of converting an Office 365 group to a Microsoft teams team. This is commonly referred to as teamifying a group. You can do this using the rest API. You do that by submitting an HTTP put to the groups team endpoint and then you pass in a JSON object that configures the new team as you can see here. Microsoft teams also have some additional settings that aren't present in Office 365 groups. For example things related to channels or animated gifs and if a user can edit or delete their own messages. That's additional things you got to make sure you keep in that you set when you update a group to a team. The same process can be done using the Microsoft graph .net SDK as you can see with this sample. Now you'll notice in this sample that you have the same properties that you can set in the rest API that I just showed you previously. Now another aspect of the teamwork endpoint that you need to be familiar with is something called resource specific permissions or RSC. These types of grants are very important. This is a Microsoft teams and a Microsoft Graph permission that enables your app to use API endpoints to manage specific resources either teams or chats within an organization. The RSC permissions model enables team owners and chat owners to grant consent for an application to access and modify the teams data and the chats data respectively. Make sure you're not only familiar with RSC but how to use the Microsoft Graph to list permission grants within a group and how to also list the permission grants on a group. You can do that using the rest API by just submitting an HTTP get to the grass v1 slash groups slash ID slash permission grants. The Microsoft Graph documentation links and learning module about working with groups cover everything you need to know related to this endpoint so use those to practice if you aren't familiar with any of the topics that I've covered throughout this lesson. Okay that wraps up my talk on groups and did teamwork endpoints and working with groups when it comes to the Microsoft Graph. If you have any questions about what I've covered here please drop a comment below or let me know if you want to see more videos about Microsoft Graph development or something else. If you like this video please give me a thumbs up and subscribe by smashing that big red subscribe button below the video so you'll see when I publish more videos for web and cloud developers on Microsoft 365 and Microsoft Azure topics. I'm Donald again. Thanks for watching. I hope to see you next time.