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

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]