May 20, 2026

The End of EWS: Migrating to Microsoft Graph with Glen Scales [MVP]

Microsoft is ending support for Exchange Web Services (EWS) in Exchange Online, with full retirement starting October 2026. The article explains why this matters for Microsoft 365 administrators, developers, ISVs, backup vendors, and enterprises still relying on legacy integrations. EWS has been a core API for mailbox access, calendar synchronization, migrations, archiving, and third-party tools for years, but Microsoft is now pushing organizations toward Microsoft Graph as the modern replacement.

The article highlights that this is not just a technical API change. Many existing applications, scripts, automation processes, monitoring tools, and enterprise workflows still depend heavily on EWS. Organizations that fail to identify these dependencies early may face outages, broken integrations, compliance risks, or unsupported applications once Microsoft disables the service.

A major focus is the migration challenge. While Microsoft Graph offers a modern, secure, and unified API model, feature parity with EWS is still incomplete in some scenarios. Companies therefore need to evaluate workloads carefully, test Graph-based alternatives, and work with vendors to ensure compatibility before the cutoff date.

The article also discusses the security background behind Microsoft’s decision. Following several security incidents and Microsoft’s broader Secure Future Initiative, legacy authentication and older Exchange protocols are being aggressively retired in favor of modern authentication, Zero Trust principles, and Graph-based access models.

Practical recommendations include auditing existing EWS usage, identifying affected applications, reviewing third-party vendor roadmaps, modernizing authentication, and starting migration projects early instead of waiting until 2026.

You want to move from legacy APIs like EWS and Azure AD Graph API to Microsoft Graph with confidence. The clock is ticking. Microsoft will start retiring EWS in October 2026 and fully disable it by April 2027. Azure AD Graph API enters retirement phase on June 30, 2023, and all apps must enable extended access by February 1, 2025. Check out the timeline below:

Service	Retirement Start	Full Disablement	Risks
EWS	Oct 1, 2026	Apr 1, 2027	Teams must map EWS scripts to Microsoft Graph before cutover to avoid disruptions.
Azure AD Graph	Jun 30, 2023	Sep 2025	Apps not enabled for extended access stop working after Feb 1, 2025.

Migrating to Microsoft Graph gives you a unified API, modern security, and better compatibility. You get streamlined development, improved productivity, and a future-proof system. Migrating from EWS to Microsoft Graph is manageable. With the right approach, you can tackle migration and API migration with ease.

Key Takeaways

Microsoft will retire EWS by April 2027 and Azure AD Graph API by February 2025. Act quickly to avoid service disruptions.
Migrating to Microsoft Graph provides a unified API, modern security, and better compatibility with Microsoft services.
Use Microsoft’s Graph Migration Analysis Tool to audit your current use of legacy APIs and identify what needs to change.
Map your old API calls to Microsoft Graph equivalents to ensure a smooth transition and maintain app functionality.
Implement a clear test plan after migration to validate that all features work as expected and catch any issues early.
Set up monitoring tools to track the health of your applications and receive alerts for any problems.
Focus on high-impact features first during migration to build momentum and demonstrate value to your team.
Utilize Microsoft Graph SDKs to simplify the integration process and reduce the complexity of your code.

Why Migrate to Microsoft Graph API

End of EWS and Azure AD Graph

You need to act fast. The end of life for EWS and Azure AD Graph API is coming soon. Microsoft will retire EWS by April 2027. Azure AD Graph API will stop working for apps not enabled for extended access after February 2025. If you delay migration, you risk losing access to important services and facing compressed timelines. Take a look at the risks in the table below:

Risk Type	Description
Restricted or unstable access	You may face limited or unreliable access to EWS-based services.
Migration tool failures	Migration tools may fail or provide incomplete results.
Compressed timelines	Tight deadlines increase pressure on IT teams.
Data loss and migration errors	Higher chances of data loss or errors during migration.
Fewer support options	Fewer supported options or workarounds will be available.

You want to avoid these risks. Migrating to Microsoft Graph API now gives you more time to plan and test your apps. You can keep your services running smoothly and stay ahead of the end of life deadlines.

Benefits of Microsoft Graph API

Microsoft Graph API offers enhanced functionality and a unified endpoint. You can connect to Microsoft 365, Azure Active Directory, and other services using one API endpoint. This makes development easier and gives you comprehensive functionality. Check out the differences between Microsoft Graph API and legacy APIs:

Feature	Microsoft Graph API	Azure AD Graph API	EWS
Support for multiple platforms	Yes	No (only .NET)	Yes
Unified endpoint	Yes	No	No
Advanced features	Yes (delta sync, batching)	Limited	Limited
Authentication method	OAuth 2.0	Basic Authentication (deprecated)	Basic Authentication (deprecated)
Integration with Microsoft services	Extensive	Limited	Limited

You get advanced features like delta sync and batching. Microsoft Graph API supports modern authentication and works across many platforms. You can build new apps or upgrade existing ones with graph APIs. Microsoft recommends Microsoft Graph API for all new applications. Azure AD Graph API will not get new features. EWS is being phased out. You want to use Microsoft Graph API to future-proof your apps and take advantage of unified endpoint access.

Security Improvements

Security matters. Microsoft Graph API uses OAuth 2.0 and a strong permissions model. You can choose delegated permissions or application permissions. This lets you control who can access data and how apps interact with Microsoft services. Here’s a quick look at the permissions model:

Permission Type	Description
Delegated permissions	Allow the application to act on behalf of the signed-in user.
Application permissions	Allow the app to access data on its own, without a signed-in user.

Applications must submit a valid access token to access protected resources. Access tokens include claims that validate identity and permissions. Both the user and the app permissions are checked for delegated access. Microsoft Graph API protects you from vulnerabilities found in legacy APIs. For example, Exchange Hybrid Privilege Escalation and Azure AD Token Validation Failure allowed attackers to escalate privileges. Microsoft Graph API closes these gaps and keeps your data safe.

You get a secure, unified endpoint with Microsoft Graph API. You can trust your apps and services to stay protected and up to date.

Preparing for Migrating to Microsoft Graph

Getting ready for migrating to Microsoft Graph means you need a clear plan. You want to know exactly what you have, what needs to change, and how to make the switch as smooth as possible. Let’s break down the steps so you can tackle api migration with confidence.

Audit Legacy API Usage

Start by figuring out where your current systems use legacy APIs like EWS and Azure AD Graph. This step helps you see the full picture of your legacy app infrastructure. Here’s how you can audit your dependencies:

Use Microsoft’s Graph Migration Analysis Tool to scan your applications. This tool will show you which apps rely on Azure AD Graph APIs.
Check Microsoft Entra (formerly Azure AD) for built-in recommendations. These tools help you spot outdated Azure AD Graph API dependencies fast.

You can also use PowerShell to check your current EWS settings:
# Check current EWS settings
Get-OrganizationConfig | Select-Object EwsEnabled, EwsAllowList
# Add your app to the AllowList
Set-OrganizationConfig -EwsAllowList @{Add="your-app-client-id"}
Set-OrganizationConfig -EwsEnabled $true
These commands help you see which apps are using EWS and make changes if needed.

Some tools make this process even easier:

Immediate Actionability: See usage details for both technical and non-technical team members.
Export Flexibility: Export your findings to CSV for sharing or further analysis.
Visualization and Time-Framing: Spot trends and justify your migration investment.
Direct Line to Stakeholders: Find out which apps and owners are behind EWS calls, so you can work together.

By taking these steps, you get a clear view of where your api migration needs to start.

Identify Affected Apps and Workloads

Once you know where the legacy APIs are in use, you need to find out which apps and workloads will be affected by the migration. This helps you prioritize and plan your next moves. Here’s a simple process to follow:

Register a new Azure AD app with only the permissions you need. Get admin consent for these permissions.
Use certificate-based authentication for automation tasks. This is more secure than client secrets.
Make sure your PowerShell host has the latest Microsoft Graph PowerShell SDK and ExchangeOnlineManagement modules.
Run an app-usage workflow to discover which apps use EWS-related permissions.
Check sign-in activity and audit logs to see which apps are actively using EWS.
Cross-check user license assignments to see which users might be impacted.
Sort your apps by recent activity. Focus on the most active ones first.

You can use tools like:

Microsoft 365 Admin Center (Reports > Usage > Exchange > EWS usage)
Find-EwsUsage.ps1 script
Microsoft Graph PowerShell SDK
ExchangeOnlineManagement modules

This process helps you build a prioritized list. You can focus on high-impact apps and workloads first, making your migration more efficient.

Map EWS and Azure AD Graph Calls to Microsoft Graph

Now it’s time to map your old API calls to their new Microsoft Graph API equivalents. This step is key for a successful migration. Here’s what you should do:

Reimplement your EWS logic using Microsoft Graph where possible. Use OAuth for better security.
Take advantage of Microsoft’s migration tools and guidance. These resources include mapping guides and AI-assisted tutorials to help you convert EWS calls to Graph.
Test and redeploy your apps. Make sure everything works as expected, especially for important features like calendar free/busy, delegate access, and complex mailbox queries.

When you migrate your apps, you’ll notice some important architectural changes. For example, Microsoft Graph uses webhooks instead of the old streaming notifications. This means you’ll need to update how your apps handle notifications and sync data.

Here’s a quick comparison of the two approaches:

Feature	EWS (Exchange Web Services)	Microsoft Graph
Purpose	Legacy SOAP-based API for accessing Exchange mailbox data directly.	Modern REST-based API for accessing Microsoft 365 data via a unified endpoint.
API Style	XML/SOAP	JSON/REST
Main Use	On-premises Exchange or older M365 apps	Cloud (Microsoft 365) only — unified access to Exchange Online, Teams, Azure AD, etc.

You get a unified endpoint with Microsoft Graph. This makes it easier to connect to different Microsoft 365 services. The switch from SOAP to REST also makes api interactions simpler and more modern.

Tip: Microsoft Graph lets you create smarter workflows and automate tasks that used to take a lot of manual work. You can connect to more data and build richer apps.

When planning your migration, remember to:

Prepare your environment before you start. Set up access controls, backups, monitoring, and compliance policies.
Focus on high-impact use cases first. Quick wins help build support for the broader migration.
Run pilot migrations with smaller datasets to test your process.
Get all stakeholders involved early. This includes IT, security, compliance, and business leaders.
Set up monitoring from day one. Track performance and usage to catch issues early.

By following these steps, you set yourself up for a smooth transition. Migrating to Microsoft Graph doesn’t have to be overwhelming. With the right approach, you can modernize your systems, improve security, and unlock new possibilities with Microsoft Graph API.

Updating Permissions and Authentication

Moving to Microsoft Graph means you need to rethink how your apps handle permissions and authentication. This step is key for keeping your environment secure and making sure your apps work smoothly with Microsoft 365.

Microsoft Graph Permissions Model

You’ll notice right away that Microsoft Graph uses a different permissions model than EWS or Azure AD Graph. With Microsoft Graph, you can choose between delegated permissions and application permissions. Here’s how they compare:

The permissions model lets you grant application permissions, so your app can access resources without a signed-in user.
EWS mostly uses delegated permissions, which means actions happen in the context of a user.
EWS also has a strong RBAC model with impersonation, but it wasn’t built for application permissions.
Microsoft Graph gives you more control with application access policies. You can restrict which mailboxes an app can reach, even if it has broad permissions.

Exchange and its RBAC model were not designed with 'application permissions' in mind, creating some challenges. The workaround made it possible to create an Azure AD integrated application and assign the full_access_as_app permission, which allows the app to have full access via EWS to all mailboxes without a signed-in user.

This new model helps you follow the principle of least privilege. You only grant the permissions your app truly needs.

Transition from Legacy Authentication

Switching from legacy authentication to modern authentication is a must. Microsoft Graph relies on OAuth 2.0, which is more secure and supports features like multi-factor authentication (MFA). Here’s a simple plan to help you make the switch:

Tell your IT teams and users about the changes. Make sure everyone knows what’s coming.
Replace old tools with ones that support OAuth 2.0. Turn on MFA for all accounts.
Review your admin consent policies. Set up approval workflows for third-party apps.

You can also update user sign-in preferences and MFA states using Microsoft Graph endpoints. For example:

To update sign-in preferences:
PATCH /users/{id | userPrincipalName}/authentication/signInPreferences
To update MFA state:
PATCH /me/authentication/requirements
PATCH /users/{id | userPrincipalName}/authentication/requirements

Modern authentication keeps your data safer and helps you meet compliance needs.

Azure AD App Registration for Microsoft Graph

Registering your apps in azure active directory is a big part of the migration. When you register an app, you set up how it will connect to Microsoft Graph and what api permissions it will need. Here are some best practices:

Pick a clear name, logo, and publisher info for your app.
Decide who will consent to your app—users or admins.
Request only the permissions you need.
Understand the difference between static, dynamic, and incremental consent.
Plan for multi-tenant scenarios if your app will be used by more than one organization.

Topic	HTTP error code	Best practice
User doesn't have access	403	Show a simple "Access denied" message to the user.
Not found	404	Remember, some resources can be restored within 30 days of deletion.
Throttling	429	Use the Retry-After delay to recover from throttling quickly.

Taking these steps in azure active directory helps your apps run smoothly and securely with Microsoft Graph.

Refactor Code for Microsoft Graph

Replace EWS to Graph Calls

You’re ready to roll up your sleeves and start replacing EWS calls with Microsoft Graph API calls. This step is where you’ll see the biggest changes in your code. You want to make sure your apps keep working and take advantage of new features.

Start by mapping out which applications still use EWS and which ones already support Microsoft Graph. Use a dependency mapping strategy to get a clear picture. You can also run a health checker script to assess your Exchange servers and their roles. This helps you spot any hidden dependencies before you begin your migration.

When you plan your migration, think about change management. You’ll need to time your updates and configure allow-listing to keep everything running smoothly. Here’s a quick table to help you organize your approach:

Strategy	Description
Dependency Mapping	Identify which applications still use EWS and which have Graph-ready versions.
Health Checker Script	Use this script to assess existing Exchange servers and their roles.
Change Management	Plan for timing and configuration of allow-listing to ensure a smooth transition.

As you refactor, you’ll run into some common challenges. Some workflows need special attention, especially if you work with archive mailboxes or public folders. Advanced delta semantics differ between EWS and Graph, so you may need to rework parts of your code. Creating mail from raw MIME with MAPI extended properties can also require you to rethink your workflows. Here’s a table that highlights these challenges:

Challenge Description
Archive mailbox access and some mailbox import/export workflows require special attention.
Public folders scenarios need engagement with Microsoft for dependencies.
Advanced delta semantics differ between EWS and Graph, necessitating rework.
Creating mail from raw MIME with MAPI extended properties may require re-architecting workflows.

You want to test each change as you go. Start with simple email and calendar features, then move on to more complex scenarios. This way, you can catch issues early and keep your migration on track.

Tip: Focus on high-impact features first. Quick wins help you build momentum and show value to your team.

Migrate Azure AD Graph API Integrations

Now, let’s talk about moving your azure ad graph api integrations to Microsoft Graph. This step is important for keeping your identity and directory features up to date. You’ll notice some differences in how the two APIs work, so you need to pay close attention to the details.

First, review your code for any calls to the azure ad graph api. Look for endpoints like https://graph.windows.net. You’ll want to replace these with Microsoft Graph endpoints, such as https://graph.microsoft.com. Here’s a side-by-side example:

Task	Azure AD Graph API Example	Microsoft Graph API Example
Example request	GET https://graph.windows.net/contoso.com/users?$filter=startswith(givenName,'Dan')&api-version=1.6	GET https://graph.microsoft.com/v1.0/users?$filter=startswith(givenName,'Dan')

You’ll also see changes in how you add, list, or remove group members. The endpoints look a little different, so make sure you update your code to match. Here’s a quick comparison:

Task	Azure AD Graph API	Microsoft Graph API
Add member	POST /groups/{id}/$links/members	POST /groups/{id}/members/$ref
List members	GET /groups/{id}/$links/members	GET /groups/{id}/members/$ref
Remove member	DELETE /groups/{id}/$links/members/{id}	DELETE /groups/{id}/members/{id}/$ref

When you migrate, remember that Microsoft Graph returns only a subset of properties by default. If you need more data, use the $select query parameter to ask for extra properties. This helps you keep your apps fast and efficient.

You’ll also notice that Microsoft Graph uses the property name id instead of objectId. Some resources, like applications and service principals, support an alternate key called appId. Update your code to use these new property names.

Note: Always test your integration after each change. This helps you catch any issues with permissions, data, or API responses.

Handle Data Model Differences

Handling data model differences is a key part of api migration. You want your apps to work the same—or better—after you switch to Microsoft Graph. The main differences show up in property names, default responses, and how you request data.

In azure ad graph api, every entity has a unique identifier called objectId. In Microsoft Graph, this is now called id. Some entities, like applications and service principals, also have an appId property you can use as an alternate key. Make sure you update your code to use these new names.

Microsoft Graph returns only a default set of properties for many resources. If you need more details, use the $select parameter in your queries. For example, if you want to get a user’s full profile, you can write:

GET https://graph.microsoft.com/v1.0/users?$select=displayName,mail,jobTitle,department

This approach keeps your API calls fast and reduces the amount of data you need to process.

You’ll also see changes in how you manage group memberships. The endpoints are different, so double-check your code. Here’s a quick table to help you compare:

Task	Azure AD Graph API	Microsoft Graph API
Add member	POST /groups/{id}/$links/members	POST /groups/{id}/members/$ref
List members	GET /groups/{id}/$links/members	GET /groups/{id}/members/$ref
Remove member	DELETE /groups/{id}/$links/members/{id}	DELETE /groups/{id}/members/{id}/$ref

When you handle these differences, you make your migration smoother and your apps more reliable. You also unlock new features and better performance with Microsoft Graph API.

Callout: Take time to document every change you make. Good documentation helps your team understand the new data model and speeds up future updates.

Migrating from ews to microsoft graph and updating your azure ad graph api integrations can feel like a big job. But with a clear plan, careful testing, and attention to detail, you’ll set your organization up for success. You’ll also get the benefits of modern graph apis, improved security, and better graph access to exchange online.

Use Microsoft Graph SDKs

You don’t have to start from scratch when you move your apps to Microsoft Graph. Microsoft Graph SDKs make your life much easier. These SDKs give you a simple way to connect your code to Microsoft 365 services. You can focus on building features instead of worrying about the details of HTTP requests or authentication.

Here’s why you’ll love using Microsoft Graph SDKs:

You get a clean and easy-to-use interface. The SDKs hide the messy parts of making raw Graph requests. You don’t need to know every detail about the protocol.
The SDKs handle common problems for you. For example, if you hit throttling limits, the SDKs know how to retry your requests. This means fewer errors and less time fixing issues.
You can work in your favorite programming language. Microsoft Graph SDKs support .NET, Java, JavaScript, Python, and more. Pick the one that fits your project best.
The SDKs help you stay up to date. When Microsoft adds new features to Microsoft Graph, the SDKs get updates too. You can use the latest tools without a lot of extra work.

Tip: If you want to build web apps or interactive dashboards, check out the microsoft graph toolkit. It gives you ready-made web components that connect to Microsoft Graph with just a few lines of code.

Let’s look at a quick example. Here’s how you can use the Microsoft Graph .NET SDK to get a list of users:

var users = await graphClient.Users
    .Request()
    .GetAsync();

foreach (var user in users)
{
    Console.WriteLine(user.DisplayName);
}

You don’t have to write long blocks of code or handle authentication by yourself. The SDK takes care of it. This saves you time and helps you avoid mistakes.

When you use Microsoft Graph SDKs, you speed up your migration. You also make your apps more reliable and easier to maintain. Your team will thank you for choosing the smart path.

Testing After Migration

You’ve done the heavy lifting. Now, you need to make sure everything works as expected. Testing after migration helps you catch issues before your users do. Let’s walk through how you can build a solid test plan, check your apps, and avoid common mistakes.

Build a Test Plan

Start with a clear test plan. This plan keeps you organized and helps you cover all the important areas. Here’s a simple way to build your plan:

List all the applications you migrated to Microsoft Graph.
Identify the main features for each app. Think about email, calendar, contacts, or directory access.
Write down the expected results for each feature.
Set up a test environment that matches your production setup.
Assign team members to run the tests and record the results.

Tip: Test both simple and complex scenarios. Don’t forget edge cases, like large mailboxes or special permissions.

Validate Functionality and Performance

You want your apps to work just like before—or even better. To validate functionality and performance, follow these steps:

Understand the changes between the old and new api endpoints. Review how your apps used Azure AD Graph and how they now use Microsoft Graph.
Check all resources that your apps touch. Look at service principals, users, and groups.
Update your code to use the new graph endpoints. Make sure you handle new data formats and response types.
Adapt your apps to any changes in data structure. For example, Microsoft Graph uses JSON instead of XML.
Run your tests in a safe environment. Try out every feature and see if the results match your expectations.
Migrate non-critical systems first. Watch how they perform before moving on to important apps.

You can use webhook notifications to get real-time updates when data changes. Delta query helps you keep your data in sync without extra work. JSON batching lets you combine requests and speed up your apps.

Note: Always monitor performance during testing. Look for slow responses or errors. Fix them before you go live.

Address Common Pitfalls

Testing helps you avoid common pitfalls. Here are some things to watch out for:

Missing permissions: Double-check that your apps have the right permissions in Microsoft Graph.
Data mismatches: Make sure your apps handle new property names and formats.
Throttling: If you send too many requests, Microsoft Graph may slow you down. Use the SDKs to handle retries.
Notification changes: Webhooks replace old notification methods. Test that your apps receive updates correctly.
Incomplete migration: Don’t forget to update all api calls. Even one missed call can cause problems.

If you run into trouble, check the logs and error messages. They often point you in the right direction. Keep your team in the loop and share what you learn.

Testing after migration gives you peace of mind. You know your apps work well with Microsoft Graph, and your users stay happy.

Monitor and Optimize Post-Migration

After you finish your migration to Microsoft Graph, you need to keep an eye on your apps and services. Monitoring helps you spot issues early and keeps your system running smoothly. You also want to optimize your setup so you get the most out of the improved ecosystem.

Set Up Monitoring and Alerts

You should set up monitoring tools right away. These tools help you track the health of your graph integrations and alert you if something goes wrong. Use Power BI or Azure Event Hubs to watch real-time activity. You can create dashboards that show how your apps use the graph API. Set alerts for failed requests, slow responses, or unusual spikes in usage. If you see a problem, you can fix it before it affects your users.

Tip: Segment your monitoring by team or department. This way, you can see which groups use the service most and find adoption gaps.

You want to make sure your apps stay compliant with regulatory compliance standards. Monitoring helps you catch issues that could affect your compliance status.

Analyze Usage Metrics

Tracking usage metrics gives you valuable insights. You can build an AI-powered dashboard that connects graph usage to productivity gains. Look at how different teams use the service. Measure adoption rates and see where you can improve. You might notice that some departments use the graph API more than others. This helps you target training or support where it’s needed.

Track productivity ROI, not just raw usage numbers.
Segment usage by role or department to find gaps.
Use real-time monitoring to spot trends quickly.
Measure gains in efficiency and collaboration.

When you analyze these metrics, you can make smart decisions. You might decide to add new features or adjust permissions to help your users get more from the graph API.

Continuous Improvement

You don’t want to stop after migration. Continuous improvement keeps your apps and services up to date. Set up webhook subscriptions for important endpoints like /users. Use delta queries to capture every change. Run scheduled checks every few hours to catch missed updates. Make sure your subscriptions stay valid and renew them when needed.

Batch requests for resources that change often.
Use serverless setups to process data efficiently.
Check for faults and fix them before they cause trouble.

Callout: Document your monitoring and improvement steps. Good records help your team learn and adapt faster.

By following these steps, you keep your graph integrations strong. You make sure your apps stay reliable and secure. You also help your organization grow with the improved ecosystem that Microsoft Graph offers.

Migrating to microsoft graph gives you a clear path to future-proof applications and unlocks real gains in productivity, security, and modernization. You can follow a structured migration plan—audit, update, refactor, test, and monitor—to keep your service reliable and avoid disruptions. Organizations see faster response times, better data consistency, and more granular permissions after migration. You also get continuous improvements in compliance and employee satisfaction. If you need help, check out these resources:

Resource	Description
EWS to Microsoft Graph Migration Guide Series	Step-by-step guidance for planning and troubleshooting migration.
Cross-tenant Migration API	Simplifies moving user content across Microsoft 365 tenants.
Azure AD to Microsoft Graph Migration Guide	Tools and endpoint mappings for migration.

You can embrace Microsoft Graph as your opportunity to modernize your service and build a secure foundation for the future.

FAQ

How long does it take to migrate from EWS or Azure AD Graph to Microsoft Graph?

Migration time depends on your app’s size and complexity. Simple apps may take days. Large or complex workloads can take weeks. Start with an audit to estimate your timeline.

Do I need to rewrite all my code for Microsoft Graph?

Not always. You can often map legacy API calls to Microsoft Graph equivalents. Some features need refactoring. Use Microsoft Graph SDKs to speed up the process.

What tools help with migration?

You can use Microsoft’s Graph Migration Analysis Tool, PowerShell scripts, and the Microsoft Graph Toolkit. These tools help you audit, map, and test your migration.

Will my users notice any changes after migration?

Most users won’t see changes if you test well. Some advanced features may work differently. Communicate updates to your users to avoid confusion.

How do I handle permissions in Microsoft Graph?

Microsoft Graph uses delegated and application permissions. Grant only what your app needs. Review and update permissions in Azure AD App Registration.

Can I run EWS and Microsoft Graph together during migration?

Yes, you can run both during migration. This lets you test Microsoft Graph while keeping EWS as a backup. Switch fully when you feel confident.

What should I do if I hit throttling limits?

Tip: Use Microsoft Graph SDKs. They handle retries for you. If you see HTTP 429 errors, slow down your requests and follow the Retry-After header.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:04,560
>> Yeah, welcome to another edition of 3MC65 show.

2
00:00:04,560 --> 00:00:06,560
Welcome everybody.

3
00:00:06,560 --> 00:00:09,200
Today, we are talking about the future of Microsoft

4
00:00:09,200 --> 00:00:13,520
Nail development, retry up and from exchange web services,

5
00:00:13,520 --> 00:00:18,520
and what developers should be doing right now to prepare.

6
00:00:18,520 --> 00:00:22,000
Joining me is Microsoft MVP Glenn Scales.

7
00:00:22,000 --> 00:00:24,240
Glenn has been written about

8
00:00:24,240 --> 00:00:30,560
Exchange development since 2004 and has worked across every major

9
00:00:30,560 --> 00:00:35,920
Exchange programming model from CDO, web dev through EVSN,

10
00:00:35,920 --> 00:00:37,600
now Microsoft Graph.

11
00:00:37,600 --> 00:00:40,720
His blog posts, shell libraries,

12
00:00:40,720 --> 00:00:44,880
tech overflow answers, and subspecathetic have helped thousands of

13
00:00:44,880 --> 00:00:49,120
developers, those real world messaging challenge.

14
00:00:49,120 --> 00:00:55,920
So you've been building the exchange over 20 years.

15
00:00:55,920 --> 00:01:02,480
What first got you into messaging development?

16
00:01:02,480 --> 00:01:08,640
>> It is been interesting, one, my first job was with SAP.

17
00:01:08,640 --> 00:01:11,840
I used to do a user conference every year,

18
00:01:11,840 --> 00:01:16,240
so I was tasked with installing Exchange and building the system,

19
00:01:16,240 --> 00:01:20,320
and then doing provisioning for every user at that conference.

20
00:01:20,320 --> 00:01:24,560
Back then, having an email address for a conference was a big thing.

21
00:01:24,560 --> 00:01:29,840
So my first Exchange code was a provisioning system for that conference.

22
00:01:29,840 --> 00:01:35,040
Then it grew gradually from there.

23
00:01:35,040 --> 00:01:40,720
Back then, I guess, in your mail development was the cutting edge,

24
00:01:40,720 --> 00:01:45,520
not so much today, it's more legacy, so I had things that moved on to teams

25
00:01:45,520 --> 00:01:51,440
and other things on the CIO at the moment, but that's sort of grown out of that.

26
00:01:51,440 --> 00:01:58,880
>> Yeah, when you look back at the evolution from on-premix change to Microsoft 365,

27
00:01:58,880 --> 00:02:04,320
what changed the most for the developers?

28
00:02:04,320 --> 00:02:09,440
>> I think it was probably more the shift from EWs to Graph,

29
00:02:09,440 --> 00:02:13,520
that you went from the third protocol now to rest.

30
00:02:13,520 --> 00:02:17,120
There's a lot more interaction with open source library,

31
00:02:17,120 --> 00:02:18,560
so it's a lot more easier to use.

32
00:02:18,560 --> 00:02:28,480
The shift to Microsoft 365 has been obviously greater authentication,

33
00:02:28,480 --> 00:02:29,680
so you've got OAuth now.

34
00:02:29,680 --> 00:02:34,880
The fundamentals of the mail API hasn't changed that much.

35
00:02:34,880 --> 00:02:41,680
>> You worked through CDO, WebDev, EBS, and now Graph.

36
00:02:41,680 --> 00:02:47,040
What lessons has Microsoft carried forward and what got left behind?

37
00:02:47,040 --> 00:02:54,320
>> I think they've learned that they should have kept developing the Graph.

38
00:02:54,320 --> 00:03:00,240
There was a big development effort in until about 2008,

39
00:03:00,240 --> 00:03:03,920
and then they kind of stopped, and they didn't hit the feature parity side of it.

40
00:03:03,920 --> 00:03:06,960
Then obviously, when midnight Blizzard came along,

41
00:03:06,960 --> 00:03:12,320
and obviously that attacked the Microsoft executive, things like that.

42
00:03:12,320 --> 00:03:14,880
They said security is a big issue for them now,

43
00:03:14,880 --> 00:03:17,680
and there's no granular security within EWs,

44
00:03:17,680 --> 00:03:21,280
so that's kind of why it's basically being depreciated.

45
00:03:21,280 --> 00:03:27,840
I think that they should have kept on that development path of Graph to get it to parity.

46
00:03:27,840 --> 00:03:32,480
They're running a bit of catch-off now, so there's some things that aren't quite there,

47
00:03:32,480 --> 00:03:34,800
but they're working hard to get there, I guess.

48
00:03:34,800 --> 00:03:43,440
You blocked the KFAMES because it covered undocumented behavior and edge cases.

49
00:03:43,440 --> 00:03:50,080
Why do exchange artists tend to have so many gray areas?

50
00:03:50,080 --> 00:03:57,040
>> I think it probably goes back to just the legacy of Mappy,

51
00:03:57,040 --> 00:03:59,920
so Mappy is a particle.

52
00:04:01,360 --> 00:04:06,240
It was developing the 80s, so the underlying data structures are a big different.

53
00:04:06,240 --> 00:04:08,480
It's a lot of business, a lot of binary stuff there.

54
00:04:08,480 --> 00:04:12,480
How they store information, it's a little bit different as well.

55
00:04:12,480 --> 00:04:17,200
There are just underlying complexities in

56
00:04:17,200 --> 00:04:20,720
calundering more than email-emails relatively simple,

57
00:04:20,720 --> 00:04:23,600
but you go under things like encryption and sign,

58
00:04:23,600 --> 00:04:24,960
it gets a little bit more complicated.

59
00:04:24,960 --> 00:04:30,880
I think a recurring meeting and how they store that as a data structure

60
00:04:30,880 --> 00:04:38,080
in Mappy is very different from how it's stored in mine, for instance,

61
00:04:38,080 --> 00:04:40,640
or the open protocols that are out there.

62
00:04:40,640 --> 00:04:42,480
It's very different.

63
00:04:42,480 --> 00:04:45,680
It goes back to the proprietary nature of exchange.

64
00:04:45,680 --> 00:04:52,480
I'm not in exchange, and what's the active directory that become the underlying substrate

65
00:04:52,480 --> 00:04:54,640
that powers Microsoft 365 now?

66
00:04:54,640 --> 00:05:00,000
>> You are really long in the business.

67
00:05:00,000 --> 00:05:09,360
What were some of the strangers or hardest exchange development issues you have ever been met?

68
00:05:09,360 --> 00:05:18,560
>> I worked for a number of years in migration.

69
00:05:18,560 --> 00:05:22,880
Obviously, migrating when people came online,

70
00:05:22,880 --> 00:05:25,600
I was either pretty much the same for Microsoft 365,

71
00:05:25,600 --> 00:05:27,680
so migrating people from the on-prem.

72
00:05:27,680 --> 00:05:31,120
The cloud, that was years of work.

73
00:05:31,120 --> 00:05:35,600
Public folder migration was probably a couple of years

74
00:05:35,600 --> 00:05:41,120
building different types of migration apps that work,

75
00:05:41,120 --> 00:05:45,520
it gets very complicated.

76
00:05:45,520 --> 00:05:49,520
We public-bole was when things get split across multiple stores.

77
00:05:49,520 --> 00:05:54,240
I think it should get routed to the back end.

78
00:05:55,600 --> 00:06:00,400
The cloud is very challenging as well because it's a little bit of a black box.

79
00:06:00,400 --> 00:06:06,400
You have a quite sure where it's getting routed,

80
00:06:06,400 --> 00:06:10,960
and mailboxes may be getting moved in the background while you're trying to push data into them.

81
00:06:10,960 --> 00:06:14,320
It creates a number of different challenges.

82
00:06:14,320 --> 00:06:19,280
You've got to make sure that your apps are always very resilient when you're dealing with

83
00:06:19,280 --> 00:06:21,040
anything sort of a email related, I guess.

84
00:06:22,320 --> 00:06:25,600
Yeah, I left this jump into the big news.

85
00:06:25,600 --> 00:06:33,760
Microsoft is trying Exchange Maps Services in October, October 2006.

86
00:06:33,760 --> 00:06:39,200
What exactly is that once being described?

87
00:06:39,200 --> 00:06:47,600
There, that depreciating AWS itself in October, so it's in four months time.

88
00:06:49,520 --> 00:06:53,040
If you have an application that's using AWS at all,

89
00:06:53,040 --> 00:06:57,760
line of business application, contact management applications,

90
00:06:57,760 --> 00:07:04,160
Siri, integration, in October, they're going to switch something in the tenant so that

91
00:07:04,160 --> 00:07:06,080
AWS requests a plot.

92
00:07:06,080 --> 00:07:09,440
You can switch it back on for about six months.

93
00:07:09,440 --> 00:07:18,000
You basically get to April to rectify or migrate or fix whatever you didn't sort of know

94
00:07:18,000 --> 00:07:26,080
was there. But after April 20, 27, there'll be no AWS in the cloud.

95
00:07:26,080 --> 00:07:29,840
It only affects the cloud, so if you have on-prem servers,

96
00:07:29,840 --> 00:07:32,560
AWS is still the API, still the go-to API,

97
00:07:32,560 --> 00:07:36,320
but any applications that are using AWS,

98
00:07:36,320 --> 00:07:38,800
access the cloud, or Microsoft 365,

99
00:07:38,800 --> 00:07:43,120
there's you in October, you're going to find that,

100
00:07:43,120 --> 00:07:47,520
you know, unless you've done something within your tenant to make sure that it doesn't happen,

101
00:07:48,080 --> 00:07:52,080
then it'll be blocked, but you then can switch it back on, but then you've got six months

102
00:07:52,080 --> 00:07:55,840
to sort of mitigate anything that you didn't mitigate at that point.

103
00:07:55,840 --> 00:08:03,200
How can organizations figure out if they have applications,

104
00:08:03,200 --> 00:08:05,120
depend on EDS?

105
00:08:05,120 --> 00:08:11,200
Within the admin portal, there's a usage,

106
00:08:12,960 --> 00:08:17,840
the AWS usage report that will tell you which AWS operations are in use,

107
00:08:17,840 --> 00:08:24,720
and which application IDs are using those, there's operations.

108
00:08:24,720 --> 00:08:27,840
So there's also other scripts that you can run the workout,

109
00:08:27,840 --> 00:08:32,800
then within that application ID, what, what clients are then using,

110
00:08:32,800 --> 00:08:34,800
why IP addresses are then using it.

111
00:08:34,800 --> 00:08:38,480
But yeah, you need to look at the admin portal,

112
00:08:38,480 --> 00:08:42,880
look at the exchange usage reports, and there's a separate AWS screen there,

113
00:08:42,880 --> 00:08:47,920
we'll show you which application IDs, and then you need to track by the application ID,

114
00:08:47,920 --> 00:08:51,680
what that's doing, whatever it's associated with a, you know,

115
00:08:51,680 --> 00:08:57,680
a line-up business application, or an ISP's application, or a Microsoft endpoint that's accessing.

116
00:08:57,680 --> 00:09:04,000
Awesome. And then you see the new suit, yeah, okay, if you just,

117
00:09:07,760 --> 00:09:10,800
the switch is now to graph, right?

118
00:09:10,800 --> 00:09:16,640
Yeah, yeah, okay, which replettes are the easiest to be great to graph?

119
00:09:16,640 --> 00:09:23,520
Email is the easiest because it's more or less,

120
00:09:23,520 --> 00:09:28,720
there's more or less no gaps in email,

121
00:09:28,720 --> 00:09:30,800
as sort of, you know, if you do in credit operations,

122
00:09:30,800 --> 00:09:34,240
you're sending email, that's the easiest thing to do, just by grabbing it off.

123
00:09:34,240 --> 00:09:39,840
You shouldn't really be sending email via AWS now because it's a simple migration,

124
00:09:39,840 --> 00:09:42,960
if you get straight over, there's no sort of blockers,

125
00:09:42,960 --> 00:09:47,680
they've just released the migration endpoints in,

126
00:09:47,680 --> 00:09:55,760
in graph, so it's gone GA in the last couple of weeks, so, you know, you can import messages from

127
00:09:55,760 --> 00:10:01,200
either on-prem.euws, or from, you know, from another tenant, or whatever you want to do,

128
00:10:02,400 --> 00:10:05,840
sort of your backing up or migrating, you can sort of use those,

129
00:10:05,840 --> 00:10:12,320
that endpoint to do it. The more complicated ones are probably around,

130
00:10:12,320 --> 00:10:14,160
all calendings are a little bit complicated.

131
00:10:14,160 --> 00:10:22,560
I think when you get into something like tasks, because it's, you know, tasks change to do, so

132
00:10:22,560 --> 00:10:27,440
the, some of the interfaces are a little bit incomplete, so you can't do things like access,

133
00:10:27,440 --> 00:10:34,240
the old mapy properties, the, what they call the single value properties in graph by the new

134
00:10:34,240 --> 00:10:40,080
to-do API, so that's a bit of a pain, so we're using, it's okay if you've sort of just using it

135
00:10:40,080 --> 00:10:45,200
as is, but if you've done custom things, if you have, you know, you've got, classic, you've got

136
00:10:45,200 --> 00:10:49,680
outlook forms that you've used, or other apps sort of been developed over years,

137
00:10:49,680 --> 00:10:54,960
that's kind of when you start having issues, you've sort of got to either maybe three think the

138
00:10:54,960 --> 00:11:02,400
process or, you know, try and, try and find some sort of work around to get it, get it going.

139
00:11:02,400 --> 00:11:13,120
Some has a large legend CVS application, where should they start with the migration?

140
00:11:13,120 --> 00:11:22,240
Which is, I'm, Thomas, one of the exchange guys in the protein, they developed an AI

141
00:11:22,240 --> 00:11:27,600
and an ASUS tool, so if something you can point at the code, your code base, so a bit in, obviously,

142
00:11:27,600 --> 00:11:33,440
it's been, not the work, you'll also analyse all the AWS operations are in use, and then it will

143
00:11:33,440 --> 00:11:40,000
go and suggest which graph operations you can use. Obviously, the graph SDK is a great because they,

144
00:11:40,000 --> 00:11:46,320
you know, it's kind of, all the other nine things like retries and throttling, the SDK is going to handle

145
00:11:46,320 --> 00:11:50,800
that for you, so you don't sort of have to reinvent the wheel, and it's going to make your migration

146
00:11:50,800 --> 00:11:56,320
a lot easier. So that's probably the best place to start if you're, if you're starting from,

147
00:11:56,320 --> 00:12:03,760
you've got an existing application that's written in obviously.net, take a look at that AI tool

148
00:12:03,760 --> 00:12:08,560
from the exchange team, it's able to kind of help you get most of the way there.

149
00:12:08,560 --> 00:12:13,600
And obviously, a lot of the other limzies, there's a pretty good dev, you know, they know about

150
00:12:13,600 --> 00:12:19,440
what's happening out there, if you just cut and paste your code into them, the ill suggest,

151
00:12:19,440 --> 00:12:24,720
pretty much, you'll get you nine, nine, the center of the way there. It's only the kind of places where

152
00:12:24,720 --> 00:12:31,600
there are gaps that you're going to have some issues. And are there patterns or architectures that

153
00:12:31,600 --> 00:12:42,480
migrate especially well? I think all the email stuff is pretty easy. It's just when you sort of get into

154
00:12:43,680 --> 00:12:51,600
like synchronization, synchronization is the hard part. The graph, they've got delta endpoints,

155
00:12:51,600 --> 00:12:57,920
which would quite good and lecture probably better than what was in any AWS. Some of the notification

156
00:12:57,920 --> 00:13:06,240
stuff is an issue because AWS had a few different notification patterns, they had pushed notifications,

157
00:13:06,240 --> 00:13:10,960
they had full notifications and then they had streaming notifications, streaming notifications were

158
00:13:12,160 --> 00:13:18,640
sort of a technology of the time. It sort of allowed you to have an endpoint, but you didn't have to have

159
00:13:18,640 --> 00:13:25,920
a public accessible IP and you could sort of push back down to it. They sort of used a little bit in

160
00:13:25,920 --> 00:13:32,160
teams as well as hate notifications was called behind the streams, but in graph, all you have is

161
00:13:32,160 --> 00:13:39,360
wear books. So you have to have a public accessible IP either on Azure or AWS or whatever platform

162
00:13:39,360 --> 00:13:45,120
that you want and that's going to be pushing out to that IP and then you're going to have some sort of

163
00:13:45,120 --> 00:13:50,880
notification background. Usually with those apps, they tend to be mobile apps. So there's

164
00:13:50,880 --> 00:13:58,080
whatever is sort of using on the mobile side, whether it's Apple or Android, you can sort of push

165
00:13:58,080 --> 00:14:03,920
back down to your mobile devices. So it's an architectural change if you're using streaming notifications.

166
00:14:04,960 --> 00:14:12,960
It's doable, it's just a little bit more complex. And did you see or what has the biggest mistakes

167
00:14:12,960 --> 00:14:20,240
organization make during migration and how can they prevent these mistakes?

168
00:14:20,240 --> 00:14:29,280
I just wear migration. It's just proper planning. They're not things. As long as we've got good

169
00:14:29,280 --> 00:14:36,080
planning in place, generally migrations will go relatively smoothly. The size of the data in

170
00:14:36,080 --> 00:14:41,840
migrating is always tricky. But that's when you start hitting throttling, I guess. And that's

171
00:14:41,840 --> 00:14:52,240
one of the challenges in graph is that throttling rates in graph in terms of migrating data into it

172
00:14:52,240 --> 00:15:00,560
are sort of in doing operations around it are a lot less than EWS. When EWS, you could use a lot more

173
00:15:00,560 --> 00:15:05,440
threads. You could use a lot more connections, a lot more operations. Graphs kind of limit that a

174
00:15:05,440 --> 00:15:11,280
bit. So you do need to think about how many threads you can have running against a mailbox at a time,

175
00:15:11,280 --> 00:15:16,960
how many operations that you can do and to make sure that your code is actually running

176
00:15:17,680 --> 00:15:22,880
relatively efficiently or written relatively efficiently. It's just not always a case I mean.

177
00:15:22,880 --> 00:15:30,320
And what of the one thing graph does better than EWS from your perspective?

178
00:15:30,320 --> 00:15:34,960
What's one thing that does better? It definitely does authentication better.

179
00:15:34,960 --> 00:15:45,040
That's a good question. I think it's more it's an integration then because it's using JSON,

180
00:15:45,040 --> 00:15:50,000
that means it integrates with a lot of open source libraries. So for especially for front-end

181
00:15:50,000 --> 00:15:56,480
developers, it's great because you can use whatever library you want. Using with EWS, you had

182
00:15:56,480 --> 00:16:01,520
so many XML and XMLs a lot harder to deal with if you've done with that, you'll know that.

183
00:16:01,520 --> 00:16:07,440
So JSON, it kind of made things in the development world a lot easier.

184
00:16:07,440 --> 00:16:12,960
The easy applications are to build generally the more reliable they are as well.

185
00:16:14,160 --> 00:16:20,560
At the end of the day, every change is I think it's hard for people and

186
00:16:20,560 --> 00:16:27,040
is there one thing the developer still miss from EWS?

187
00:16:27,040 --> 00:16:38,400
I think it's just the way it was in it. EWS obviously built back in 2007 and kind of when they

188
00:16:39,120 --> 00:16:48,160
built things in 2007, they tended to engineer them better so you've got access to most things and

189
00:16:48,160 --> 00:16:56,160
there's less sort of, at the time EWS came out, we were comparing parity against MATBE and

190
00:16:56,160 --> 00:17:02,880
EWS never hit sort of parity with MATBE either, but it got pretty much all the way there.

191
00:17:03,600 --> 00:17:12,880
And it became an easier way to access any of the MATBE and then the APIs that proceeded it.

192
00:17:12,880 --> 00:17:21,200
Probably what we miss most with EWS is sort of that accessibility and

193
00:17:21,200 --> 00:17:26,640
it's just the sort of knowledge base that's built up over the years because

194
00:17:26,640 --> 00:17:32,160
people's applications they kind of tend to evolve over years. So most EWS code bases

195
00:17:32,720 --> 00:17:37,520
that are around now are very mature or scripts that people have built very mature, they're unreliably.

196
00:17:37,520 --> 00:17:42,800
Now they've got to go to another API and they sort of have to go through that process again

197
00:17:42,800 --> 00:17:48,480
flying out where the bugs are, get to that mature point where their code is going to run reliably

198
00:17:48,480 --> 00:17:50,000
and be happy with it, I guess.

199
00:17:50,000 --> 00:17:57,360
Yeah, I have a look a little bit in your block and also as they are for the people,

200
00:17:57,360 --> 00:18:00,880
they have to find all the links from you in the show notes.

201
00:18:02,480 --> 00:18:06,560
But yeah, you've written extensively about graph made APIs.

202
00:18:06,560 --> 00:18:12,240
Where has graph nature the most in the recent years?

203
00:18:12,240 --> 00:18:20,400
I think since they announced an appreciation they started working again on actually

204
00:18:20,400 --> 00:18:22,880
improving it or adding stuff back into it.

205
00:18:22,880 --> 00:18:29,200
You can see from the change of log bit there was this massive gap from basically 28 aims.

206
00:18:30,480 --> 00:18:35,040
2023 where it kind of not much changed at all and they didn't add anything in there.

207
00:18:35,040 --> 00:18:40,800
Now they're evolving, they're adding new endpoints. I think some of the recent one was the

208
00:18:40,800 --> 00:18:45,040
user configuration endpoints. So now you can access those user configuration

209
00:18:45,040 --> 00:18:53,120
items which basically sort of moves in more and allows you to automate things behind the scenes

210
00:18:53,120 --> 00:18:59,360
which can be a, it's sort of, it's an enabler for applications.

211
00:18:59,360 --> 00:19:04,320
So that's, yeah, it's an important, it's kind of one of the, I guess one of the things that gets a bit

212
00:19:04,320 --> 00:19:11,760
lost between EWS and Graph. Because EWS you have access to the mailbox, it's a great enabler for

213
00:19:11,760 --> 00:19:16,080
kind of anything you want to do if you want to create a shortcut or you want to sort of build some sort of

214
00:19:16,080 --> 00:19:22,720
thing that's sort of just outside the norm of what Microsoft are doing.

215
00:19:22,720 --> 00:19:27,120
EWS is the great enabler for that. With graph you're a bit more locked down. So

216
00:19:28,160 --> 00:19:34,000
things like newer features like Outlook, Broming, Signatures, there's still no API to do that.

217
00:19:34,000 --> 00:19:37,600
It's just a bit of a, a bit of a pain coin I think.

218
00:19:37,600 --> 00:19:47,920
And which newer graph endpoints or capabilities are, yeah, developers all by looking?

219
00:19:50,800 --> 00:19:58,640
I've probably the import export APIs, an important one because it sort of gives you back full access to

220
00:19:58,640 --> 00:20:05,440
everything. Before that you couldn't really access every mouth folder and a mailbox. You couldn't

221
00:20:05,440 --> 00:20:11,120
access every item within a mailbox now you can sort of do that now with the import and export API

222
00:20:11,120 --> 00:20:19,440
which is good. There are things like the folder associated items that are quite allow you access to

223
00:20:19,440 --> 00:20:26,320
which is a bit of pain. But it's kind of, it's a bit of a get out of your card for a lot of things

224
00:20:26,320 --> 00:20:31,120
that the mailbox import export API. If you're doing things that are sort of outside of the norm, I think.

225
00:20:31,120 --> 00:20:40,480
You have core rights sending me my messages with graph. Why is mine still important in modern

226
00:20:40,480 --> 00:20:47,840
mail workflows? I guess because it's sort of the open standard to, you know,

227
00:20:47,840 --> 00:20:55,040
a lot of people, if you have a mail, just an outside of exchange, you have Gmail, you know,

228
00:20:55,040 --> 00:21:01,440
whoever it is, those messages are going to be mine. So being able to put those my messages back

229
00:21:01,440 --> 00:21:06,800
into exchange or converting for all my converting to, it's pretty important. A lot of line and

230
00:21:06,800 --> 00:21:12,000
business applications, once you take a message outside of exchange, they'll store it natively in

231
00:21:12,000 --> 00:21:18,800
mine. Exchange is a bit of an outlier, I guess, from a storage point of view in it because it's own

232
00:21:18,800 --> 00:21:24,160
sort of proprietary way of storing messages which isn't mine. So the things get converted to

233
00:21:24,160 --> 00:21:30,960
and from mine when they hit the exchange store. What are your recommendations for handling large

234
00:21:30,960 --> 00:21:39,360
mailbox operations efficiently in graph? I think, yeah, they are challenging graph,

235
00:21:40,560 --> 00:21:46,080
especially, you know, if you're doing large-scale data discoveries, so you're looking at,

236
00:21:46,080 --> 00:21:52,320
so you're crawling a mailbox and you want to look at every item in a mailbox for a particular reason,

237
00:21:52,320 --> 00:21:58,720
because you're teaching LLM about the user's behavior all the way. They use messages or whatever

238
00:21:58,720 --> 00:22:07,120
the communications are. I think, you know, having good filtering and trying not to get,

239
00:22:07,120 --> 00:22:14,160
trying not to do too much, I guess at once. If you have notification applications,

240
00:22:14,160 --> 00:22:20,480
you may get a notification storm, but graph restricts you to four connections to a mailbox. So you

241
00:22:20,480 --> 00:22:26,240
need to make sure that you probably queue those operations, did you pick a item where you can,

242
00:22:26,240 --> 00:22:30,000
and make sure you don't sort of go over that four connection limit or your applications,

243
00:22:30,000 --> 00:22:36,880
not going to work the way you want it to work. Yeah, I read some of those discussions,

244
00:22:36,880 --> 00:22:44,800
are Delta queries and change notification made sure that enough for enterprise ground

245
00:22:44,800 --> 00:22:54,800
syncs or solutions? I'm just written in an article about that, which will come out somewhere

246
00:22:54,800 --> 00:23:03,680
soon, hopefully. I'm saying yes, because that means the older streaming notifications,

247
00:23:03,680 --> 00:23:11,520
if you built a streaming notification app on exchange, getting it to unreliably in the cloud was

248
00:23:11,520 --> 00:23:18,320
challenging, because with a streaming notification app, it had to have a connection 24 hours a day,

249
00:23:18,320 --> 00:23:22,240
two year mailbox, and if that mailbox moved in the cloud, that connection would generally break.

250
00:23:22,240 --> 00:23:29,200
You'd have to re-subscribe a lot of times. So getting it to unrelibe was tricky. Once you had

251
00:23:29,200 --> 00:23:38,640
to code base there, it was generally fine. DeGraph, things like webbooks, because they were a cloud

252
00:23:38,640 --> 00:23:46,800
native, and a lot of those pre, the old notification mechanisms in AWS, they were built before the

253
00:23:46,800 --> 00:23:53,120
cloud ever existed. So they're all sort of pre-cloud, and then they sort of, they do obviously work

254
00:23:53,120 --> 00:23:59,600
within the cloud, but not as well as the stuff that was built post, so things like the webbooks and

255
00:23:59,600 --> 00:24:06,080
graph work a lot more efficiently in the deltas. Well, the deltas operations are generally better

256
00:24:06,080 --> 00:24:14,560
than in the graph, and then they are in AWS. And when you can, what lessons should

257
00:24:14,560 --> 00:24:18,400
you develop as to learn about batching and pagination? Early on?

258
00:24:21,760 --> 00:24:27,280
Yeah, batching is an interesting one. I don't really agree with the batch limits that

259
00:24:27,280 --> 00:24:33,200
are in place in the graph. It's kind of a one-size-fits-all. It's 20 items for every workload.

260
00:24:33,200 --> 00:24:43,680
I know in AWS, because I work in the migration space, the best sort of point was around 50 items

261
00:24:43,680 --> 00:24:49,040
a batch for doing migrations. You could sort of optimize up and down a little bit,

262
00:24:50,320 --> 00:24:57,120
depending on how large the items were, were you were importing or exporting? So you kind of lose

263
00:24:57,120 --> 00:25:05,360
that flexibility, so you sort of, you're stuck at the 20 item matches. They have actually fixed

264
00:25:05,360 --> 00:25:14,880
because there was a bug in exchange where we were with batching in graph, where if you tried to

265
00:25:14,880 --> 00:25:21,040
batch 20 items, it would actually try to occur at all concurrently, so it would just basically exceed the

266
00:25:21,040 --> 00:25:28,880
mailbox concurrence you limit. But now it sort of handles it for you, so, but you're still limited

267
00:25:28,880 --> 00:25:36,960
to that sort of one batch of 20 items, which will then, you know, it'll be run concurrently across

268
00:25:36,960 --> 00:25:44,560
the fourth threads that are available for the mailbox. Those concurrent bread limits are a little

269
00:25:44,560 --> 00:25:53,120
bit lower or a little bit too low, so try to get myself to change them, but it's hard, it's hard to get

270
00:25:53,120 --> 00:26:02,880
that across the line. I think you can say it from Microsoft. I've said it, and I've said it repeatedly,

271
00:26:02,880 --> 00:26:09,040
and I said it repeatedly when they first introduced that limit, and they didn't listen to me back then.

272
00:26:11,200 --> 00:26:17,360
Maybe they'll just steal a little bit more these days, but it was crazy at the time they did it,

273
00:26:17,360 --> 00:26:23,360
and I tried to get that at point across to them. Yeah, we have more crazy now.

274
00:26:23,360 --> 00:26:29,200
If you have a look into performance in Spanish, I will look a little bit more in the

275
00:26:29,200 --> 00:26:36,080
out-itification and security part. How has modern authentication changed,

276
00:26:37,360 --> 00:26:45,520
changed, exchange, developed, I think it's changing in a good way. I mean, we had a couple of years ago,

277
00:26:45,520 --> 00:26:52,480
we had the basic or the depreciation, so, and that should have really highlighted to people

278
00:26:52,480 --> 00:26:57,760
which apps are running EWS. They should know from back then, I guess, obviously company,

279
00:26:57,760 --> 00:27:02,560
you know, employment, employment changes, people sort of come and go, so they should know which

280
00:27:02,560 --> 00:27:09,200
applications and that depreciation, I use EWS and they should know which ones to target for this

281
00:27:09,200 --> 00:27:17,920
depreciation. I think it's made things easier. I hope people aren't hard coding, using

282
00:27:17,920 --> 00:27:22,080
them in passwords in their scripts and in for at least seeing a lot of that over the years.

283
00:27:22,080 --> 00:27:30,560
But yeah, access tokens are a great thing, you know, having a time back access token that only

284
00:27:30,560 --> 00:27:36,880
lasts for one hour, it's a hell of a lot more secure than it was. But yeah, we're moving away from

285
00:27:36,880 --> 00:27:46,080
EWS impersonation now and more granular emissions in graph is kind of where the benefits are coming in,

286
00:27:46,080 --> 00:27:51,760
you know, that's kind of where we're, it's way we're trying to move for a more secure future, I guess.

287
00:27:56,560 --> 00:28:03,840
Yeah, but when we look a little bit about, I say, the old on-prem time and now we are in the cloud

288
00:28:03,840 --> 00:28:14,160
first time, do developers fully understand how much security architect are matters now compared to

289
00:28:14,160 --> 00:28:23,920
the older exchange models, especially on-prem? I hope so. And that, you know, the granular

290
00:28:23,920 --> 00:28:29,840
emissions in graph is kind of why why Mark's afraid to appreciate in EWS, you know, you sort of,

291
00:28:29,840 --> 00:28:36,240
you have an application that needs to access any sort of mail data within EWS, you kind of have to

292
00:28:36,240 --> 00:28:40,960
give it everything. So it gets access to all your email, all your calendar, all your tasks,

293
00:28:40,960 --> 00:28:47,680
everything, all you send email. But you know, graph has things so you can, you can just limit it to

294
00:28:47,680 --> 00:28:54,400
basic mail read access. You can, I mean, if you just want needed to access email, then you can just

295
00:28:54,400 --> 00:29:00,960
access email if you did just to send email, you can just let it send email. So I think that's an

296
00:29:00,960 --> 00:29:07,440
important thing probably to consider when you are migrating from EWS to graph is to look at those

297
00:29:07,440 --> 00:29:14,080
granular emissions and start logging it down, you start looking at, you know, least restrictive,

298
00:29:14,080 --> 00:29:19,760
you know, the least restrictive you can make your emissions for your applications and that's,

299
00:29:19,760 --> 00:29:26,880
you know, it's kind of benefit you going down the track. What was the biggest out-and-this-take you

300
00:29:26,880 --> 00:29:38,000
still see in production? I think over, it's security wise, it's overuse of impersonation because

301
00:29:38,000 --> 00:29:44,080
once you're labeling EWS impersonation, you give it access to everything within your tenant,

302
00:29:44,080 --> 00:29:55,440
which is generally a bad thing. Yeah, I think impersonation, the use of impersonation is probably the

303
00:29:55,440 --> 00:30:02,560
the worst wealth, yeah. And not, not, not ordering is well, not ordering your permission use.

304
00:30:04,160 --> 00:30:10,400
Is it probably a bad thing as well? But that's a good question actually. What's your

305
00:30:10,400 --> 00:30:13,120
preference deck today to build mail integrations?

306
00:30:13,120 --> 00:30:22,960
I guess if you're building integrations, you're building integrations into clients, is that

307
00:30:22,960 --> 00:30:27,360
what the question is about? Because, yeah, obviously, obviously mail add-ins because,

308
00:30:27,360 --> 00:30:32,160
obviously work across, they're going to work across new outlook, they're going to work across

309
00:30:32,160 --> 00:30:37,680
outlook on the web. You generally shouldn't be building con base plugins for a classic half-look,

310
00:30:37,680 --> 00:30:45,120
even though it's in some ways an nicer API and more fully-featured API, you should be doing mail add-ins.

311
00:30:45,120 --> 00:30:52,320
I actually kind of like the mail add-in, I haven't done them for a while, but the ones I've built

312
00:30:52,320 --> 00:30:55,840
kind of like the development, sort of the experience around those.

313
00:30:58,160 --> 00:31:05,840
Are our power shell and scripting automations still underrated and Microsoft 365 development from your

314
00:31:05,840 --> 00:31:14,160
perspective? I don't know, underrated. I mean, I installed OpenCore a while ago, I'm starting to

315
00:31:14,160 --> 00:31:19,760
play around with that and if you look, on Windows, it just writes power, shawlscripts that access the

316
00:31:19,760 --> 00:31:26,640
exchange to a vial graph. It doesn't write particularly good ones either. That's the one thing you're

317
00:31:26,640 --> 00:31:31,440
looking at code efficiency, you know, OpenCore as I think is an example of something that can tend to

318
00:31:31,440 --> 00:31:36,720
not write very efficient scripts or it's possible because the LAMs are been using, but

319
00:31:36,720 --> 00:31:44,320
I think, yeah, I think with power shell scripting, LAMs are getting a lot better at writing them these days.

320
00:31:44,320 --> 00:31:50,080
So I used to do a lot of work, you know, to sort of one-offs for people with writing power

321
00:31:50,080 --> 00:31:56,560
shell scripts to do particular admin features and functions and any of these days, you can get an LAM to

322
00:31:56,560 --> 00:32:03,920
write that sort of stuff. I think a lot of people ask for the admin side of exchange, the admin APIs,

323
00:32:03,920 --> 00:32:11,920
why aren't they in graph? I kind of think that's an overrated thing to be honest.

324
00:32:11,920 --> 00:32:19,040
I would, there is there is a there is rest APIs that back a lot of that stuff now that a private

325
00:32:19,040 --> 00:32:26,960
and if you're smart enough you can make use of those. Yeah, a little better.

326
00:32:26,960 --> 00:32:39,600
So I'm a, I use script runner, I love it. What tools or SDKs do you find yourself recommending most

327
00:32:39,600 --> 00:32:48,640
often? Primarily the power shell graph SDK. It's a lot easier to use.

328
00:32:49,600 --> 00:32:55,200
Most things you can sort of get down to a couple of lines of code, but it's, I think, from our reliability

329
00:32:55,200 --> 00:33:02,480
perspective because it handles throttling, it handles retries. It's also, you know, it's availability,

330
00:33:02,480 --> 00:33:08,080
it's kind of easy to get out there if you're writing stuff for customers. They're going to be happy with

331
00:33:08,080 --> 00:33:15,840
it. Otherwise, and the generally the code at writes is a lot more readable as well. I find people

332
00:33:15,840 --> 00:33:20,560
tend to find that a lot more readable and what more usable for them. So yeah, the

333
00:33:20,560 --> 00:33:23,280
generally I would sort of recommend the power shell SDK.

334
00:33:23,280 --> 00:33:34,160
You are blogging since 2004. Like, this is amazing. It's over 20 years.

335
00:33:34,160 --> 00:33:43,280
Yeah, that is really amazing. What motivated you to keep documenting all this technical details?

336
00:33:45,280 --> 00:33:50,400
I guess personally, I'm kind of a maker at heart. I think some of the the maker ethos is to actually

337
00:33:50,400 --> 00:33:57,840
share what you're doing, share what you create. And then when I started to direct more with the

338
00:33:57,840 --> 00:34:04,160
community, you would get questions from people. So how can I do this? And if you could come up with

339
00:34:04,160 --> 00:34:11,840
a solution, that'd be great. And that creates great material for the blog. I think a lot of that's

340
00:34:11,840 --> 00:34:17,360
changed in the last couple of years because of all the elements. You know, a sub stack is kind of

341
00:34:17,360 --> 00:34:24,160
died off. Unfortunately, so you get a lot less. So those foreign based questions and interactions

342
00:34:24,160 --> 00:34:29,040
with the community. So I find a lot of my sub stack material is sort of me interacting with

343
00:34:29,040 --> 00:34:35,440
the elements and getting bad answers and bad information. And sort of I've sort of tried to

344
00:34:35,440 --> 00:34:42,080
really double down on creating more and more long sort of long technical articles to teach the

345
00:34:42,080 --> 00:34:48,000
LL edm. So you sort of, and I find that it is working. The questions that I asked now are

346
00:34:48,000 --> 00:34:52,320
the answers are better and it's I can tell it's regurged, telling a lot of the information that I'm

347
00:34:52,320 --> 00:34:59,200
writing as well. So it's kind of, yeah, it's kind of so. But it is, you're at at at heart, I find that

348
00:34:59,200 --> 00:35:04,080
it's it's kind of the maker ethos. It's about sharing what you're doing and making, like I said,

349
00:35:04,080 --> 00:35:11,680
making other people's lives a lot easier as well. I have looked at the blog and some marketing tools

350
00:35:11,680 --> 00:35:19,120
and it's amazing. You rang out sometimes Microsoft tech community and the Microsoft

351
00:35:19,120 --> 00:35:27,760
learn really awesome. Did you expect that your blog became such a major resource for exchange

352
00:35:27,760 --> 00:35:37,840
developers or what was the plan or the, yeah, I don't know. Really, I mean, I think the first thing

353
00:35:37,840 --> 00:35:46,960
I wrote that really went viral was an RSS feed for exchange. It's a really simple thing. And going

354
00:35:46,960 --> 00:35:51,200
back a number of years, it's a simple thing. The RSS project was really simple and actually writing

355
00:35:51,200 --> 00:35:57,120
the script, I think it was written in moanad or probably murdered at the time or partial

356
00:35:57,120 --> 00:36:04,000
or what later, obviously later, they came out show. It's been a lot of fun. I think over the years,

357
00:36:04,000 --> 00:36:08,160
I've really enjoyed writing the blog and especially interacting with the community, especially the

358
00:36:08,160 --> 00:36:15,680
MVP community. You know, great bunch of people. And obviously now, obviously you get to deal with the

359
00:36:15,680 --> 00:36:24,960
the guys from the product team trying to help them across the line with the CWS migration. It's sort

360
00:36:24,960 --> 00:36:31,680
of, it's really about getting the information out there and sort of, I feel a little bit responsible

361
00:36:31,680 --> 00:36:37,200
for this EWS depreciation because a lot of people have picked up my material and it's still being

362
00:36:37,200 --> 00:36:44,480
used. So you kind of need to get them off that EWS side and into the graph stuff to make sure that

363
00:36:44,480 --> 00:36:51,920
whatever they're doing is going to continue work in the future. Yeah, a little bit looked also

364
00:36:51,920 --> 00:37:01,520
in the L&M Dinker and I see your blog is really, really often citated by L&M. So it's,

365
00:37:01,520 --> 00:37:08,320
yeah, you feed all these L&M's for free. That's a little bit dark for all.

366
00:37:08,320 --> 00:37:18,800
I don't know. I think it sort of always pays its off back. I've been freelancing since about

367
00:37:19,280 --> 00:37:31,200
2010. So, you know, it always pays its all back in jobs and customers. I don't know, maybe in the future,

368
00:37:31,200 --> 00:37:36,160
I mean, he won't. I don't know. It's all sort of take over a job, depending on who you sort of listen to.

369
00:37:36,160 --> 00:37:44,000
But I think it's, you know, we sort of move forward together. I think that's, it's always the

370
00:37:44,000 --> 00:37:49,760
thoughts. I think, you know, I think there's always a place for makers in this world. So I'm hoping I'm

371
00:37:49,760 --> 00:37:58,960
going to be okay. Yeah, it's kind of, I think, you know, you look at other, other makers around. It's kind

372
00:37:58,960 --> 00:38:08,720
of what we do. Also, I have seen your own stack overflow and you have answered over a thousand

373
00:38:08,720 --> 00:38:18,240
questions. There is also awesome. What makes, yeah, what makes exchange developer community unique,

374
00:38:18,240 --> 00:38:26,480
what should I say? Yeah, stack overflow is unfortunately dying. It's, you know, the number of

375
00:38:26,480 --> 00:38:32,080
questions. I think I've answered this year is probably within the more under a hundred, where

376
00:38:32,080 --> 00:38:41,120
you should be a couple hundred or a couple of thousand, maybe. It's, yeah, it's a bit of a shame. I find

377
00:38:41,120 --> 00:38:49,120
you know, the way people are now getting information is different. I think the exchange

378
00:38:49,120 --> 00:38:54,160
community says a whole is a bit different. There's probably, it's probably, it's eight, maybe it's

379
00:38:54,160 --> 00:39:01,040
aging out. I don't know. But I always enjoyed the the Mac conferences, which were the Microsoft

380
00:39:01,040 --> 00:39:08,880
Exchange conferences, because they sort of, it was just basically one subject. And, you know,

381
00:39:08,880 --> 00:39:14,720
all other people that attended the conferences were, were, were great. I think even, I think I got,

382
00:39:14,720 --> 00:39:19,840
I mean, people that I sort of met at those conferences, you know, I did work for four years.

383
00:39:20,400 --> 00:39:26,400
It's, yeah, exchange, these exchange movies, I don't know, it's hard to describe, I guess.

384
00:39:26,400 --> 00:39:38,320
Well, how do put in the words? And I also see, yeah, if you contribute a lot to open source projects,

385
00:39:38,320 --> 00:39:43,840
and it's there one project tool you are especially proud of.

386
00:39:46,720 --> 00:39:56,480
I wrote, I wrote a, really early on I wrote, I call it exe-rest, which was kind of, it was a precedence

387
00:39:56,480 --> 00:40:01,440
to what is now the power show for our FSTK. It was kind of, because there wasn't anything before that,

388
00:40:01,440 --> 00:40:08,080
so I wrote, I wrote a library, I still use it personally, because there's a lot of stuff I find that

389
00:40:08,080 --> 00:40:16,080
is good in the, yeah, open source is an interesting,

390
00:40:17,040 --> 00:40:21,200
topic, especially when we're talking about depreciation, because, you know, there's a lot of EWS

391
00:40:21,200 --> 00:40:28,160
open source libraries that other people maintain, where they haven't really got out the message

392
00:40:28,160 --> 00:40:34,240
that EWS has been depreciated in exchange online, so, yes, for anyone listening to this,

393
00:40:34,240 --> 00:40:39,520
if you are using one of those libraries, and there's a popular Python library, there's popular PHP ones,

394
00:40:39,520 --> 00:40:45,760
yeah, just, just take a look at that one, because they're the things that are going to be as easy

395
00:40:45,760 --> 00:40:50,800
to my games from, because there are an open source library, there's a lot of effort that's been put in

396
00:40:50,800 --> 00:40:57,280
them to make them user friendly, so, you kind of, you're moved to graph, maybe a little bit more trickier,

397
00:40:57,280 --> 00:41:04,000
so yeah, do you think, you know, but source maintainer is really hard, so I'm not having a guy

398
00:41:04,000 --> 00:41:10,080
with those people that are maintaining those projects, but I would like for those people to be

399
00:41:10,080 --> 00:41:15,680
putting on their front pages, say, people that are on Microsoft 365, they're using this library,

400
00:41:15,680 --> 00:41:20,000
okay, look at your migration path, because that's, it's going to be an issue for you.

401
00:41:20,000 --> 00:41:29,040
Do you think graph eventually becomes the single RPS service for all Microsoft's of 65 workloads?

402
00:41:29,040 --> 00:41:37,920
Yeah, good question. I would, it would be good if it did become that,

403
00:41:39,520 --> 00:41:47,680
you know, graph has been a, it's a really great idea conceptually, but it can be a bit of a blocker

404
00:41:47,680 --> 00:41:52,480
for innovation, because it tends to be slow for things to come on to, you know,

405
00:41:52,480 --> 00:41:57,840
Microsoft reliefs, new features, and then there's maybe two or three years before you see the long graph,

406
00:41:57,840 --> 00:42:04,160
so it's, yeah, it's not, I think, from a competitive nature in the environment, in the tech

407
00:42:04,160 --> 00:42:09,520
environment, in the enterprise fees, they kind of need that, you know, they need that as soon as a

408
00:42:09,520 --> 00:42:14,880
a feature is released in the outlook client or on exchange online that they have access to it,

409
00:42:14,880 --> 00:42:21,120
you know, they can use it in whatever they want, every, they want to do it, to build their businesses.

410
00:42:21,120 --> 00:42:26,240
I think that's, that's an important thing that gets me spy Microsoft and the graph, I think.

411
00:42:29,920 --> 00:42:36,880
Where do you think Microsoft made development is heading over the next three, five, ten years?

412
00:42:36,880 --> 00:42:46,320
I hope that they've learned their lesson and that they've, they will start lighting up new

413
00:42:46,320 --> 00:42:55,440
endpoints in, in the graph, because, you know, as a whole, my older brother is a bit a bit static,

414
00:42:56,800 --> 00:43:01,200
you know, you got to a conference, you don't see sessions on male development in more,

415
00:43:01,200 --> 00:43:07,920
you know, reading everyone sort of moved on to teams or other collaboration platforms.

416
00:43:07,920 --> 00:43:15,200
I think there's still, you know, there's still, there's still, there's still potential in, in

417
00:43:15,200 --> 00:43:21,280
male development. I think, you know, people have been trying to kill off the email for ages,

418
00:43:21,920 --> 00:43:28,800
that's saying email is dead, you know, in some ways, it, in some ways, excuses changed.

419
00:43:28,800 --> 00:43:34,320
I will see a lot of people use teams these days, but there's still a whole bunch of, you know,

420
00:43:34,320 --> 00:43:39,760
business and other things that email is kind of critical for and will go on being critical for.

421
00:43:39,760 --> 00:43:47,920
So we need good APIs to, I mean, you could APIs and people working within, in that space to kind of,

422
00:43:47,920 --> 00:43:55,200
or ours to, to have that technologies and I have those APIs as an enableer for whatever we're doing.

423
00:43:55,200 --> 00:44:01,920
Obviously AI and how our co-pilot is going to access and how that's going to change things within

424
00:44:01,920 --> 00:44:06,960
the client, um, spear is going to be interesting and that's probably where the action's going to

425
00:44:06,960 --> 00:44:12,800
happen the next couple of years, I guess. Okay, awesome. So now come one of my favorite panels.

426
00:44:14,480 --> 00:44:20,400
Overall sessions, it's the rapid fire rounds. So I asked a question and if the,

427
00:44:20,400 --> 00:44:27,040
what was coming your mind as an answer? So you, your favorite exchange version.

428
00:44:27,040 --> 00:44:32,720
2007, I think it was easy, it introduced AWS.

429
00:44:32,720 --> 00:44:37,280
Most animated graph capability.

430
00:44:39,760 --> 00:44:47,040
I think port export for the moment. Yeah. One API feature you wish Microsoft world at tomorrow.

431
00:44:47,040 --> 00:44:50,560
Roaming signatures, definitely Roaming signatures.

432
00:44:50,560 --> 00:44:53,280
Tepsil space.

433
00:44:53,280 --> 00:44:57,360
Uh, what was the question?

434
00:44:57,360 --> 00:44:59,280
Tepsil space.

435
00:44:59,280 --> 00:45:03,680
Our tabs are space. Um, I use tabs.

436
00:45:05,520 --> 00:45:14,400
Uh, Paola show or C#? Um, C#, it's just, but I, I'd ride everything in Paola show still.

437
00:45:14,400 --> 00:45:18,160
Like I said, I think I think Paola show is just, you know, what easy for people to understand.

438
00:45:18,160 --> 00:45:22,000
One day, back in the tool, you can't live without.

439
00:45:22,000 --> 00:45:28,800
Uh, Fidler and the AWS editor, I think probably and, and Mappy,

440
00:45:29,600 --> 00:45:35,120
Macy, that'd be sorry. It was like someone's like, I'll leave without. At the last round,

441
00:45:35,120 --> 00:45:38,240
best piece of care, career advice you ever received.

442
00:45:38,240 --> 00:45:47,680
Best piece of career advice. I don't know. I've never received much career advice.

443
00:45:47,680 --> 00:45:57,120
So yeah, yeah, we, we are running out of time. So, uh, yeah, my,

444
00:45:57,920 --> 00:46:05,760
my final question is, this listener's take a way one thing about EBS,

445
00:46:05,760 --> 00:46:07,680
retry, what should it be?

446
00:46:07,680 --> 00:46:14,720
Um, login to your portal tomorrow and look at your AWS usage report and see what,

447
00:46:14,720 --> 00:46:20,880
what's being used. That's, that's really important because, you know, the time to migrate is, is now,

448
00:46:20,880 --> 00:46:25,840
or you, you should have really done it. Um, but obviously a lot of end is still catching up.

449
00:46:26,800 --> 00:46:32,320
But yeah, you've only got sort of four months till the, I guess the first switch off happens. And then,

450
00:46:32,320 --> 00:46:38,400
um, after that, you've got sort of six months to sort of remediate anything that you can

451
00:46:38,400 --> 00:46:43,840
remediate and then it's going to go completely. Um, if you're using public folders, you know,

452
00:46:43,840 --> 00:46:52,240
public folders are sort of an, I sort of going away from all the AWS terms are, I'm going to

453
00:46:52,240 --> 00:46:56,480
be unexcessible. So you're going to need to look for another solution there as well.

454
00:46:57,040 --> 00:46:59,120
If you are using AWS against public folders.

455
00:46:59,120 --> 00:47:08,320
Yeah, awesome. So thank you. Uh, I think, yeah, I would say all the people show, look at your

456
00:47:08,320 --> 00:47:15,920
GitHub, Stack Overflow, a sub-stack, and so on. So we find all the links in the, uh, show notes.

457
00:47:15,920 --> 00:47:22,560
It was awesome. Uh, I learned a lot. And yeah, uh, I think I have to look

458
00:47:25,280 --> 00:47:34,480
over your, have some legend systems. And yeah, so thank you so much for joining and yeah,

459
00:47:34,480 --> 00:47:39,680
have a, have a great day. And yeah, bye. Thank you. Awesome. Yeah. Thanks, bro.

460
00:47:39,680 --> 00:47:40,880
It's been great to be here.

461
00:47:40,880 --> 00:47:42,880
(laughs)

462
00:47:42,880 --> 00:47:44,880
[The chatbox continues]

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

Glen Scales

Developer

Glen Scales is a Microsoft MVP and senior developer based on the Sunshine Coast, Australia, specializing in Exchange, Active Directory, Office 365, and Teams. He's been blogging about mail development and Exchange since 2004 — over 20 years of hands-on, in-the-trenches technical writing that has become essential reading for anyone building on Microsoft's messaging platform.

Glen's expertise runs deep across every Exchange programming model — from the early days of CDO and WebDAV through Exchange Web Services to the Microsoft Graph API. His blog posts and code samples don't just explain how things *should* work; they map out the undocumented corners, the gray areas, and the practical workarounds that only surface when you're building real solutions. Whether it's sending MIME messages via Graph, migrating directory access code from EWS, or navigating large attachment uploads, Glen has been there first and written the guide.

He shares his tools and PowerShell libraries openly on GitHub, is a trusted voice on Stack Overflow with over one thousand answers, and now publishes his latest work on his [eMail Development Substack](https://glenscales.substack.com/). If you've ever searched for an answer to an Exchange development question, chances are Glen's work pointed you in the right direction.