Episode 367 – Azure Files vs a Server with an SMB Share

January 04, 2024

Episode Transcript

In Episode 367, Ben and Scott kick off 2024 with a discussion of Azure Files. They start out reviewing a customer scenario Ben encountered and how they would approach it, breaking down the options available with Azure Files, hosting traditional SMB shares in Azure, and how a hybrid deployment can be the best of both worlds.

Like what you hear and want to support the show? Check out our membership options.

Show Notes

About the sponsors

Intelligink utilizes their skill and passion for the Microsoft cloud to empower their customers with the freedom to focus on their core business. They partner with them to implement and administer their cloud technology deployments and solutions. Visit Intelligink.com for more info.

See full episode transcriptTranscript is autogenerated by AI

1 00:00:03,365 --> 00:00:06,175 - Welcome to episode 367 2 00:00:06,195 --> 00:00:08,695 of the Microsoft Cloud IT Pro Podcast 3 00:00:09,255 --> 00:00:12,135 recorded live on December 29th, 2023. 4 00:00:12,565 --> 00:00:14,975 This is a show about Microsoft 365 5 00:00:14,975 --> 00:00:17,815 and dasher from the perspective of it pros at end users 6 00:00:18,225 --> 00:00:20,695 where we discuss a topic or recent news 7 00:00:20,755 --> 00:00:23,495 and how it relates to you to kick off the new year. 8 00:00:23,635 --> 00:00:26,055 We start out talking about some changes coming 9 00:00:26,075 --> 00:00:28,015 to the podcast in 2024. 10 00:00:28,465 --> 00:00:32,015 After that, we dive into hosting file shares on Azure 11 00:00:32,235 --> 00:00:33,415 and some things to consider. 12 00:00:33,675 --> 00:00:36,415 We briefly touch on comparing this to SharePoint, 13 00:00:36,475 --> 00:00:40,215 but then spend the bulk of our time on a hosted Azure server 14 00:00:40,245 --> 00:00:41,535 with an SMB share 15 00:00:41,795 --> 00:00:44,495 or using Azure storage in the file share 16 00:00:44,815 --> 00:00:46,015 functionality of that service. 17 00:00:48,275 --> 00:00:52,055 Oh, we made it Scott, our last recording 18 00:00:52,395 --> 00:00:54,415 of 2023, our 19 00:00:54,415 --> 00:00:55,655 - Last recording of 2023. 20 00:00:55,795 --> 00:00:58,575 And it's gonna be our first recording of 2024. Yes. 21 00:00:58,845 --> 00:01:01,935 - Because we are live with those 22 00:01:02,725 --> 00:01:06,815 Discord members in 2023 and this will come out. 23 00:01:07,515 --> 00:01:09,135 So we didn't talk about this, Scott, 24 00:01:09,155 --> 00:01:12,695 and this is a good segue maybe is this is, I'm assuming, 25 00:01:12,695 --> 00:01:14,335 going to come out January, 26 00:01:15,795 --> 00:01:17,695 six days from now. Four, five, 27 00:01:18,005 --> 00:01:19,005 - Something like that. 28 00:01:19,375 --> 00:01:20,495 - Thursday, - It should be January 29 00:01:20,765 --> 00:01:22,295 four, Thursday the fourth. 30 00:01:22,635 --> 00:01:24,655 - Yes. And then you 31 00:01:24,655 --> 00:01:26,215 and I, so we do this every once in a while. 32 00:01:26,215 --> 00:01:27,895 We'll go out for breakfast, out for coffee 33 00:01:28,155 --> 00:01:31,655 and discuss Podcasty stuff and what we wanna do 34 00:01:31,955 --> 00:01:33,815 and what we're going to do. 35 00:01:34,155 --> 00:01:38,855 And we went out for coffee a week or so ago, right 36 00:01:38,855 --> 00:01:40,895 before the Christmas holiday 37 00:01:41,635 --> 00:01:45,055 and discussed the podcast in 2024. 38 00:01:45,675 --> 00:01:49,855 And as such, are going to make some changes going into 2024. 39 00:01:50,285 --> 00:01:52,095 - Yeah, real quick, let's, let's get through this. 40 00:01:52,255 --> 00:01:56,495 So, all right, this will be episode 367 when it comes out. 41 00:01:56,875 --> 00:01:59,535 So if you do some quick back of the napkin math, 42 00:02:00,155 --> 00:02:03,135 that's at least one episode a week for the past seven years. 43 00:02:03,525 --> 00:02:05,095 Give, give or take, we're like six 44 00:02:05,095 --> 00:02:06,895 and a half pluses coming on seven. 45 00:02:06,895 --> 00:02:08,615 Sometimes we've released more episodes. 46 00:02:08,765 --> 00:02:11,055 - Yeah, I think March will be seven. 47 00:02:11,405 --> 00:02:13,335 - Yeah. During conferences and things like that. 48 00:02:13,335 --> 00:02:15,255 But it's been a while. Like we've been on this kind 49 00:02:15,255 --> 00:02:18,455 of continuous march to, to get this thing out the door. 50 00:02:18,755 --> 00:02:21,615 So in 2024 we're going to do that 51 00:02:21,615 --> 00:02:23,055 and we're absolutely gonna keep it going, 52 00:02:23,515 --> 00:02:26,615 but we are going to change a few things up. 53 00:02:26,875 --> 00:02:30,775 So first is, you and I kind of both talked about this 54 00:02:30,835 --> 00:02:35,055 and we wanna get back into deeper dives on specific areas 55 00:02:35,715 --> 00:02:38,255 either you know, that could be like a service in Azure, 56 00:02:38,425 --> 00:02:41,095 could be a new, you know, component 57 00:02:41,095 --> 00:02:42,455 that's released in the Microsoft 58 00:02:42,455 --> 00:02:43,935 365 stack, something like that. 59 00:02:43,995 --> 00:02:46,735 But I think we like taking deeper dives on things 60 00:02:46,915 --> 00:02:49,695 and generally that's like where we'd want to land 61 00:02:50,355 --> 00:02:53,375 and we'll still deal the occasional like broader tech space, 62 00:02:53,755 --> 00:02:58,175 random news thing, but that should be far less frequent. 63 00:02:58,245 --> 00:03:00,245 Like we do wanna be a little bit more kind 64 00:03:00,245 --> 00:03:02,485 of focused on what we're putting out there. 65 00:03:02,945 --> 00:03:05,645 Second is, like I said, we've released at least, 66 00:03:06,025 --> 00:03:07,765 at least one episode a week 67 00:03:07,785 --> 00:03:08,965 for almost seven years straight. 68 00:03:09,635 --> 00:03:11,845 Some weeks, especially during conferences, 69 00:03:11,975 --> 00:03:13,685 we've cranked out multiple episodes. 70 00:03:13,725 --> 00:03:15,965 I remember like Ignite one year we did like 10 71 00:03:15,965 --> 00:03:17,525 or 13 episodes like that, 72 00:03:17,525 --> 00:03:18,765 like something crazy that was nuts. 73 00:03:19,025 --> 00:03:22,245 It all takes its toll. Burnout is definitely a real thing. 74 00:03:22,585 --> 00:03:24,045 You and I have talked a bunch about it. 75 00:03:24,345 --> 00:03:26,645 We both love putting this podcast together 76 00:03:27,265 --> 00:03:29,845 and figuring out the content, what to chat about each week 77 00:03:29,985 --> 00:03:31,205 and to go through that and, 78 00:03:31,265 --> 00:03:33,645 and you know, thanks to everyone who listens 79 00:03:33,645 --> 00:03:36,325 and puts up with it, but you know, you 80 00:03:36,325 --> 00:03:38,125 and I both need to be mindful of our mental health, 81 00:03:38,435 --> 00:03:40,765 certainly like where we are in our respective careers. 82 00:03:41,145 --> 00:03:43,245 And I think realistic just about the amount 83 00:03:43,245 --> 00:03:46,245 of time we spend on what's ultimately something 84 00:03:46,245 --> 00:03:47,925 that like you and I do for our enjoyment. 85 00:03:47,925 --> 00:03:51,645 Yep. We don't do this for any monetary gain. 86 00:03:51,915 --> 00:03:54,285 Like if people think that oh you've got memberships 87 00:03:54,285 --> 00:03:56,805 and you make money off that, or you've got a YouTube channel 88 00:03:56,805 --> 00:03:58,445 and maybe you make money over there, like we don't, 89 00:03:58,445 --> 00:04:00,365 we spend money, we don't make any money. 90 00:04:00,505 --> 00:04:02,645 We, we in fact lose a bunch on that. 91 00:04:03,465 --> 00:04:06,405 So with that all in mind, we're just gonna be cutting back 92 00:04:06,405 --> 00:04:07,885 to one episode every other week. 93 00:04:08,505 --> 00:04:12,765 So the intention here is to put out more quality content. 94 00:04:13,225 --> 00:04:16,565 So we wanna get back into those deep dives, 95 00:04:16,945 --> 00:04:20,725 do more interviews, ultimately be more intentional 96 00:04:21,065 --> 00:04:23,925 and less of what's on our mind in the moment. 97 00:04:24,105 --> 00:04:27,085 So I, I hope that kind of works out and comes across. 98 00:04:27,705 --> 00:04:30,485 And then third is we've been dual releasing 99 00:04:30,585 --> 00:04:32,765 to both the podcast site. 100 00:04:32,785 --> 00:04:34,805 So that comes out in your podcaster of choice. 101 00:04:34,805 --> 00:04:37,445 Could be like Apple Podcasts, could be Spotify, 102 00:04:38,105 --> 00:04:40,965 Google Podcasts, YouTube, any, anything like that. 103 00:04:41,745 --> 00:04:45,285 And we've been pushing to YouTube video at the same time. 104 00:04:45,405 --> 00:04:47,085 I think we've been a little lax on the YouTube side. 105 00:04:47,345 --> 00:04:49,285 So for any viewers that are coming in that way, 106 00:04:49,655 --> 00:04:51,965 we're gonna be working on some new things there. 107 00:04:52,025 --> 00:04:53,285 We wanna incorporate more of 108 00:04:53,285 --> 00:04:55,565 what we're talking about directly into the recordings 109 00:04:55,785 --> 00:04:58,525 and hopefully bring everyone all around on kind 110 00:04:58,525 --> 00:05:01,525 of all sides, a better all around experience. 111 00:05:02,065 --> 00:05:04,485 So with that out of the way you want 112 00:05:04,485 --> 00:05:06,525 to get into today's episode, sure. 113 00:05:06,835 --> 00:05:08,245 - Okay. So no one more thing. 114 00:05:08,465 --> 00:05:10,125 And I think with a YouTube thing too, 115 00:05:10,225 --> 00:05:13,005 and this was something that some members brought up in 116 00:05:13,155 --> 00:05:17,485 Discord, Scott, was when we're recording these in the past 117 00:05:17,835 --> 00:05:20,605 it's always just been talking heads, right? 118 00:05:20,715 --> 00:05:22,045 It's been yours 119 00:05:22,045 --> 00:05:23,365 and i's heads for those people 120 00:05:23,365 --> 00:05:25,645 that watch in Discord, they just see us. 121 00:05:25,665 --> 00:05:29,245 For those of you that watched on YouTube, it was just us. 122 00:05:29,585 --> 00:05:32,365 Uh, we are going to be starting to play around with 123 00:05:33,285 --> 00:05:36,445 actually doing, showing the screen when we're doing these. 124 00:05:36,625 --> 00:05:40,085 So if you are watching in Discord, you'll see maybe some 125 00:05:40,085 --> 00:05:41,485 of the articles that we're referencing. 126 00:05:41,485 --> 00:05:43,325 It's not necessarily gonna be demoing things, 127 00:05:43,385 --> 00:05:46,645 but as we look at different articles referenced different 128 00:05:46,645 --> 00:05:48,405 things, trying to highlight those. 129 00:05:48,505 --> 00:05:50,885 And I think this will also help if you do wanna go watch 130 00:05:50,885 --> 00:05:53,805 afterwards on YouTube doing some YouTube clips again, 131 00:05:53,805 --> 00:05:55,165 different things we'll play with with there. 132 00:05:55,495 --> 00:05:58,285 We're going to start trying to incorporate a little bit more 133 00:05:58,285 --> 00:06:01,485 of a visual aspect for those of you that are interested 134 00:06:02,265 --> 00:06:04,045 but still not take away from the audio. 135 00:06:04,135 --> 00:06:06,445 Still make sure we're explaining things in detail, 136 00:06:06,755 --> 00:06:07,845 talking through things. 137 00:06:07,945 --> 00:06:09,565 For those of you that still wanna listen to audio. 138 00:06:09,745 --> 00:06:13,405 So as we go into 2024, it might bear with us 139 00:06:13,465 --> 00:06:15,485 as we figure out some of that balance 140 00:06:15,785 --> 00:06:18,965 to really create this in a way that it works for both 141 00:06:19,485 --> 00:06:21,205 audiences a little bit better. Yeah. 142 00:06:21,205 --> 00:06:22,565 - Yes. See where it all goes. We're open 143 00:06:22,565 --> 00:06:23,805 to feedback too. Let us know. 144 00:06:23,985 --> 00:06:25,925 - Yes, absolutely end with that. 145 00:06:26,095 --> 00:06:27,405 Let's dive into it now Scott, 146 00:06:27,595 --> 00:06:30,885 with our first deep dive ish topic. 147 00:06:31,235 --> 00:06:33,845 Deep dive of 2024. 148 00:06:34,345 --> 00:06:36,605 And this is one, oh, were you gonna say something? 149 00:06:36,685 --> 00:06:39,765 I was gonna say this is one that came out of a client 150 00:06:40,495 --> 00:06:43,685 discussion that I have had in the last couple of weeks. 151 00:06:44,225 --> 00:06:47,005 It was interesting to talk through this. 152 00:06:47,105 --> 00:06:49,405 And this is around a topic 153 00:06:49,405 --> 00:06:52,405 that we have talked about on several occasions in different 154 00:06:52,765 --> 00:06:56,445 capacities around where you put your files in the cloud 155 00:06:56,905 --> 00:07:01,245 and the particular client discussion started with 156 00:07:01,775 --> 00:07:03,245 SharePoint and wanting 157 00:07:03,265 --> 00:07:05,565 to put all their files in SharePoint from a file share. 158 00:07:05,945 --> 00:07:08,445 And then their plan was just to map the SharePoint site 159 00:07:08,705 --> 00:07:09,885 as a network drive. 160 00:07:10,145 --> 00:07:12,125 So they'd still have their network drive, they'd still do 161 00:07:12,125 --> 00:07:13,765 that, but the files would just be in SharePoint 162 00:07:14,545 --> 00:07:17,005 and brought up the fact that web daf, 163 00:07:17,015 --> 00:07:19,765 which is the technology behind it, is now deprecated. 164 00:07:19,795 --> 00:07:21,885 Some of that even relies on Internet Explorer, 165 00:07:21,885 --> 00:07:23,605 which is now gone. 166 00:07:23,985 --> 00:07:26,125 And that quickly pivoted to, okay, 167 00:07:26,125 --> 00:07:28,005 so maybe SharePoint isn't the best place, 168 00:07:28,105 --> 00:07:29,965 we should still do a file share. 169 00:07:30,255 --> 00:07:33,925 Which resulted in an interesting conversation 170 00:07:34,225 --> 00:07:36,245 of do we do Azure files 171 00:07:36,705 --> 00:07:41,045 or do we stand up a 20 22, 20 19 172 00:07:41,625 --> 00:07:42,925 server in Azure 173 00:07:43,305 --> 00:07:48,125 and do a typical SMB share from this Azure server. 174 00:07:48,665 --> 00:07:52,285 And so we landed on today, well let's talk about this 175 00:07:52,285 --> 00:07:56,005 around Azure files deployment, maybe even some comparison 176 00:07:56,035 --> 00:07:58,685 between doing Azure files and an Azure server 177 00:07:59,345 --> 00:08:02,685 and what those thoughts are and maybe some of the pros 178 00:08:02,685 --> 00:08:05,125 and cons, some of the parts of this customer discussion 179 00:08:05,125 --> 00:08:08,805 that came up around the decision that they made, 180 00:08:08,935 --> 00:08:11,085 which I can share at some point in time as well. 181 00:08:11,325 --> 00:08:13,725 - I think it's always an interesting conversation. 182 00:08:13,945 --> 00:08:18,085 So anything that starts outta my head with Azure files 183 00:08:18,665 --> 00:08:22,885 versus, and you mentioned versus something like just a 184 00:08:22,885 --> 00:08:25,285 traditional Windows server that's maybe out there 185 00:08:25,745 --> 00:08:28,045 and it sounded like it could have been even like an Azure 186 00:08:28,065 --> 00:08:29,165 hosted Windows server 187 00:08:29,235 --> 00:08:32,285 with just an SMB share presented from it. 188 00:08:32,635 --> 00:08:34,685 Like in the back of my head immediately I hear that, 189 00:08:34,745 --> 00:08:38,005 I'm like, why not do both , you can really have kind 190 00:08:38,005 --> 00:08:41,525 of the best of all worlds here if that's a path that you 191 00:08:42,475 --> 00:08:45,685 potentially willing to go down. 192 00:08:46,025 --> 00:08:48,205 So like if your requirement is 193 00:08:48,965 --> 00:08:52,125 SMB shares Azure files is interesting in 194 00:08:52,125 --> 00:08:54,685 that it's a kind of managed service for you. 195 00:08:54,685 --> 00:08:56,365 It's a, it's a managed storage service 196 00:08:57,145 --> 00:09:01,085 and you can access those files that are in 197 00:09:01,085 --> 00:09:02,965 that managed share in multiple ways. 198 00:09:03,185 --> 00:09:06,005 So you can do that by directly mounting 199 00:09:06,105 --> 00:09:09,805 and directly attaching to that file share that's in Azure, 200 00:09:09,835 --> 00:09:11,165 like just in a storage account. 201 00:09:11,785 --> 00:09:14,125 You know, there's considerations for networking there. 202 00:09:14,265 --> 00:09:16,765 You need line of sight from clients 203 00:09:16,985 --> 00:09:18,805 to servers, all those kinds of things. 204 00:09:19,585 --> 00:09:21,965 The other interesting thing that you can potentially do is, 205 00:09:21,985 --> 00:09:24,125 and Azure files is uniquely suited for this, 206 00:09:24,745 --> 00:09:27,045 is you confront Azure files 207 00:09:27,315 --> 00:09:30,605 with what's called a Azure file sync server. 208 00:09:30,995 --> 00:09:35,565 It's effectively a cash but it's a near cache 209 00:09:35,565 --> 00:09:39,645 and it's a hot cache that can sit closer to your clients 210 00:09:40,305 --> 00:09:41,725 and not just sit closer to your clients 211 00:09:41,785 --> 00:09:43,045 but potentially give your clients 212 00:09:43,135 --> 00:09:44,605 other functionality as well. 213 00:09:44,985 --> 00:09:46,525 So there's things that like the managed 214 00:09:46,525 --> 00:09:47,845 service might not be able to do. 215 00:09:48,625 --> 00:09:51,005 One of the ones that comes to mind for me off the top 216 00:09:51,005 --> 00:09:54,045 of my head is quick QUIC 217 00:09:54,625 --> 00:09:56,925 and being able to do SMB over quick. 218 00:09:57,025 --> 00:09:59,685 That's something that's relatively new-ish in Windows 219 00:09:59,685 --> 00:10:02,485 server, but it only exists in Windows server. 220 00:10:02,585 --> 00:10:05,045 It doesn't exist inside of Azure files, 221 00:10:05,385 --> 00:10:06,485 the managed service yet. 222 00:10:06,825 --> 00:10:10,445 But because Azure files has this Azure file sync server 223 00:10:10,475 --> 00:10:12,965 that can sit in front of it, you can kind 224 00:10:12,965 --> 00:10:16,285 of enjoy the benefits of a managed service, managed storage 225 00:10:16,825 --> 00:10:19,565 and kind of that provisioned unit of storage that sits 226 00:10:19,565 --> 00:10:21,685 behind things and all the capabilities 227 00:10:21,685 --> 00:10:22,765 that come along with that. 228 00:10:22,905 --> 00:10:25,485 Be it redundancy, data protection, anything like that. 229 00:10:25,945 --> 00:10:28,325 And then you can also front it with 230 00:10:29,105 --> 00:10:32,205 what's fundamentally just a traditional SMB server 231 00:10:32,625 --> 00:10:34,085 and do everything off of that 232 00:10:34,385 --> 00:10:37,765 and get the advantages of things like SMB over quick 233 00:10:37,905 --> 00:10:39,845 for your clients as well. 234 00:10:40,305 --> 00:10:42,285 So you don't have to worry about maybe something like, 235 00:10:42,285 --> 00:10:45,485 oh let me stand up a server, let me provision some disks, 236 00:10:45,705 --> 00:10:47,605 let me stripe a bunch of disks together. 237 00:10:47,615 --> 00:10:49,245 Maybe I build out a storage pool 238 00:10:49,585 --> 00:10:51,125 and then I create an SMB share. 239 00:10:51,285 --> 00:10:52,645 I do DFS namespace 240 00:10:52,905 --> 00:10:53,965 and present a share out 241 00:10:53,965 --> 00:10:55,685 of A DFS namespace back to my clients. 242 00:10:56,115 --> 00:10:58,325 Like it's more just, Hey, I'm gonna stand up a server, 243 00:10:58,585 --> 00:11:00,045 I'm gonna put SMB in front of it 244 00:11:00,345 --> 00:11:03,685 and rather than presenting back to local disk, 245 00:11:03,825 --> 00:11:06,085 I'm just gonna do a direct amount of my Azure file share 246 00:11:06,385 --> 00:11:08,285 or do Azure file sync into that 247 00:11:08,705 --> 00:11:12,325 and then have those components come back to your clients. 248 00:11:12,595 --> 00:11:16,645 It's kind of like the best of both worlds if you're looking 249 00:11:16,785 --> 00:11:19,085 for things like high availability, 250 00:11:19,115 --> 00:11:22,485 potentially better disaster recovery, you're looking for 251 00:11:23,705 --> 00:11:26,405 richer data protection features within your stack. 252 00:11:26,825 --> 00:11:28,965 So things like soft delete 253 00:11:29,145 --> 00:11:32,245 for accidental data protection comes to mind 254 00:11:32,945 --> 00:11:35,925 for me there you can turn on soft delete you, 255 00:11:35,945 --> 00:11:37,805 you've got managed Azure resources, 256 00:11:37,825 --> 00:11:40,325 you do Azure resource locks, all that kind of stuff. 257 00:11:41,105 --> 00:11:45,525 Or managed shares also are supported with vaulted backup. 258 00:11:46,025 --> 00:11:49,445 So you can do backups into something like Azure backup 259 00:11:49,705 --> 00:11:52,485 as well and then just kind of get all 260 00:11:52,485 --> 00:11:54,285 that wired up and running. 261 00:11:54,465 --> 00:11:58,405 So I don't know, like for me it's not a if this or that. 262 00:11:58,435 --> 00:12:01,005 It's more like hey, which one of these should you do? 263 00:12:01,025 --> 00:12:02,885 And then should you maybe do both of them together? 264 00:12:03,075 --> 00:12:04,965 Because there's, there are some real 265 00:12:04,965 --> 00:12:06,005 advantages for you there. 266 00:12:06,225 --> 00:12:07,245 - So I'm curious your thoughts. 267 00:12:07,285 --> 00:12:10,645 I have mixed feelings on doing both of them. 268 00:12:11,005 --> 00:12:12,485 I have one client that does both, 269 00:12:13,195 --> 00:12:17,525 that sometimes accesses files from Azure files directly, 270 00:12:17,595 --> 00:12:19,765 sometimes accesses them from the server. 271 00:12:20,115 --> 00:12:21,485 They have an on-premises server. 272 00:12:21,875 --> 00:12:24,045 They have run into some challenges with that, 273 00:12:24,045 --> 00:12:26,285 particularly in the frequency 274 00:12:26,435 --> 00:12:29,085 that Azure files sync happens. 275 00:12:29,665 --> 00:12:31,565 So I think there's some scenarios to think 276 00:12:31,565 --> 00:12:33,885 through there when you're comparing a both 277 00:12:33,985 --> 00:12:36,445 or comparing which one is, I would say, 278 00:12:36,695 --> 00:12:39,765 where are you accessing these files from 279 00:12:39,945 --> 00:12:41,205 and then where's your server sitting? 280 00:12:41,545 --> 00:12:45,645 And then I'm also curious on your thoughts of like benefits 281 00:12:45,645 --> 00:12:48,045 of Azure files in the cloud. 282 00:12:48,105 --> 00:12:50,685 And I know you mentioned some things like Azure backup 283 00:12:50,785 --> 00:12:54,005 and stuff, but you can also backup a VM 284 00:12:54,005 --> 00:12:56,925 and Azure is, is there a real advantage 285 00:12:56,955 --> 00:13:00,525 that you see when it comes to Azure files in the cloud 286 00:13:01,185 --> 00:13:03,925 and doing a server with a file share in the cloud 287 00:13:04,305 --> 00:13:06,125 or is this a little bit more of a 288 00:13:06,315 --> 00:13:07,765 that stretch type scenario? 289 00:13:07,765 --> 00:13:10,085 You have an on-premises server, you want the speed 290 00:13:10,085 --> 00:13:12,965 of the on-premises server when you're on-premises 291 00:13:13,425 --> 00:13:15,405 and you wanna do some of that backup, 292 00:13:15,555 --> 00:13:19,045 that redundancy et cetera up to a file share in Azure. 293 00:13:19,285 --> 00:13:21,445 I think some of those are, 294 00:13:22,185 --> 00:13:24,045 and not the discussions that I went to in this client, 295 00:13:24,045 --> 00:13:26,765 they were going to go one way or the other. 296 00:13:26,835 --> 00:13:30,005 They weren't necessarily looking for that environment 297 00:13:30,065 --> 00:13:31,525 and they were emphatic 298 00:13:31,525 --> 00:13:32,965 that everything was gonna be in Azure. 299 00:13:32,965 --> 00:13:34,925 They were getting rid of all their on-prem servers . 300 00:13:35,025 --> 00:13:36,765 And that was a discussion I started having 301 00:13:36,765 --> 00:13:40,045 with them was it never even approached the do we do both at 302 00:13:40,045 --> 00:13:41,645 what's always, do we do one or do we do the other 303 00:13:41,875 --> 00:13:44,765 because whatever we do is gonna sit in Azure. I 304 00:13:44,765 --> 00:13:46,565 - Think it's where you have to do a little bit of 305 00:13:46,565 --> 00:13:47,685 that TCO analysis. 306 00:13:47,825 --> 00:13:50,525 So one of the things that comes to mind immediately 307 00:13:50,545 --> 00:13:54,205 for me is if you're talking about things like it's 308 00:13:54,205 --> 00:13:55,245 all in Azure anyway, right? 309 00:13:55,245 --> 00:13:56,365 It's, it's a virtual machine. 310 00:13:56,515 --> 00:13:58,805 Virtual machines have disks associated with them 311 00:13:58,805 --> 00:14:00,765 so you're gonna need to probably bring in 312 00:14:00,795 --> 00:14:02,125 some data discs Yep. 313 00:14:02,345 --> 00:14:04,805 To actually host the data and get that in. 314 00:14:05,105 --> 00:14:09,245 So data disks are like a managed disk in Azure. 315 00:14:09,305 --> 00:14:13,485 Say you did like a premium V two disc, like whatever it is, 316 00:14:13,625 --> 00:14:15,565 it really doesn't matter for the most part. 317 00:14:15,565 --> 00:14:19,525 Every single one of them is pay for what you provision, 318 00:14:19,705 --> 00:14:20,805 not pay for what you use. 319 00:14:21,225 --> 00:14:25,805 So you're gonna go ahead and maybe bring in say 128 gig disc 320 00:14:25,905 --> 00:14:28,845 or 2 56 you're bringing a terabyte here, a terabyte there, 321 00:14:29,045 --> 00:14:30,965 whatever it is, you're potentially overpaying. 322 00:14:30,965 --> 00:14:33,005 So one of the TCO things is 323 00:14:33,715 --> 00:14:36,925 with Azure files you can set up your shares at potentially 324 00:14:36,925 --> 00:14:39,925 smaller sizes and just grow them over time. 325 00:14:40,235 --> 00:14:42,485 Like you don't need to stand up a new disc, you don't need 326 00:14:42,485 --> 00:14:44,765 to migrate data between them, anything like that. 327 00:14:44,835 --> 00:14:47,845 Like it's just a share that you attach to 328 00:14:48,225 --> 00:14:51,285 and you don't have to over-provision on day one. 329 00:14:51,385 --> 00:14:54,565 So I think that's kind of an important TCO consideration 330 00:14:54,565 --> 00:14:56,885 for you is just what you're putting together 331 00:14:57,385 --> 00:14:58,645 and what you're doing there. 332 00:14:59,065 --> 00:15:03,805 The other piece is you know resiliency on the backend. 333 00:15:04,265 --> 00:15:08,845 So if you think about a managed disc, you can have a disc 334 00:15:08,875 --> 00:15:12,405 that you know ultimately the end of the day like a disc has 335 00:15:12,405 --> 00:15:14,125 to live in the same zone as your vm. 336 00:15:14,275 --> 00:15:17,245 Like yeah I get their ZRS discs and things like that 337 00:15:17,545 --> 00:15:19,765 but still they really home 338 00:15:19,785 --> 00:15:22,005 to like a single data center within a region. 339 00:15:22,225 --> 00:15:24,805 So if you're looking for additional resiliency 340 00:15:25,485 --> 00:15:28,205 redundancy on the storage plane for those things, 341 00:15:28,905 --> 00:15:32,125 that's all just included in Azure files 342 00:15:32,125 --> 00:15:34,165 because it's just a standard storage account. 343 00:15:34,225 --> 00:15:37,005 So you can do things like locally redundant storage, 344 00:15:37,185 --> 00:15:38,605 you can do zone redundant storage, 345 00:15:39,265 --> 00:15:41,005 you can even do geo replicated stuff. 346 00:15:41,065 --> 00:15:42,485 So if you want to do GRS 347 00:15:42,585 --> 00:15:45,205 or GZRS, that's all available to you. 348 00:15:45,345 --> 00:15:47,645 And then you get kind of multiple flavors 349 00:15:47,905 --> 00:15:49,965 of potentially IOPS and 350 00:15:49,965 --> 00:15:53,205 and performance with things like premium versus 351 00:15:54,085 --> 00:15:55,645 standard along along the way. 352 00:15:56,245 --> 00:15:58,445 I also see a lot of customers like this 353 00:15:58,445 --> 00:15:59,565 discussion comes up quite a bit. 354 00:15:59,565 --> 00:16:00,845 Like I don't work in with a lot 355 00:16:00,845 --> 00:16:02,125 of our files customers directly 356 00:16:02,245 --> 00:16:03,325 'cause I'm more on the object side. 357 00:16:03,585 --> 00:16:05,645 But one of the things that always comes up is 358 00:16:05,825 --> 00:16:09,125 how can they use things like replication technologies like 359 00:16:09,205 --> 00:16:11,485 DFSR and stand that up 360 00:16:11,485 --> 00:16:13,445 and do they use that in their on-prem environments today 361 00:16:13,445 --> 00:16:14,925 and how does that translate to the cloud? 362 00:16:15,395 --> 00:16:18,525 Well the cool thing is it's just one managed share 363 00:16:18,845 --> 00:16:20,005 'cause all your data can live in that chair. 364 00:16:20,005 --> 00:16:22,205 It has all the data protection features, redundancy, 365 00:16:22,525 --> 00:16:24,005 resiliency, all that good kind of stuff. 366 00:16:24,385 --> 00:16:25,725 And then you can just front it 367 00:16:25,725 --> 00:16:28,085 with those file syncs wherever you want. 368 00:16:28,305 --> 00:16:30,805 So you could front it with a file sync server 369 00:16:30,805 --> 00:16:33,045 that's hosted in Azure in the case of maybe this customer 370 00:16:33,045 --> 00:16:34,725 that you're coming to talking to today 371 00:16:35,185 --> 00:16:38,325 or maybe it's a customer who really does have on-prem needs 372 00:16:38,425 --> 00:16:41,285 and cloud needs and you could have a file sync server 373 00:16:41,305 --> 00:16:44,445 that's in Azure and both on premises back 374 00:16:44,445 --> 00:16:45,485 closer to those clients. 375 00:16:45,665 --> 00:16:48,725 So having that hot cache component there I think 376 00:16:49,105 --> 00:16:50,725 is is important to you. 377 00:16:51,305 --> 00:16:54,565 You know I mentioned Azure backup having like off 378 00:16:54,565 --> 00:16:57,005 effectively like offsite backup for these kinds of things 379 00:16:57,745 --> 00:16:59,445 is something that you would have to wire up 380 00:16:59,445 --> 00:17:01,965 and do yourself like sure it's a virtual machine 381 00:17:01,965 --> 00:17:03,565 and maybe you tie that into Azure backup. 382 00:17:03,985 --> 00:17:06,525 Is it going to offer you the consistency 383 00:17:06,525 --> 00:17:07,645 model that you're looking for? 384 00:17:07,785 --> 00:17:10,925 Is it application consistent? Is it crash consistent? 385 00:17:11,035 --> 00:17:12,885 Like what's the consistency model 386 00:17:12,905 --> 00:17:14,165 and are you gonna be able to restore it 387 00:17:14,165 --> 00:17:16,685 and get it back together versus just having it in a managed 388 00:17:16,685 --> 00:17:19,965 share and then you know, if the VM goes away, who cares? 389 00:17:20,125 --> 00:17:22,045 I just spin up another VM and 390 00:17:22,625 --> 00:17:26,445 and my Azure, you know file share is still sitting there 391 00:17:27,105 --> 00:17:30,565 and then you know the last thing on TCO is it kind 392 00:17:30,565 --> 00:17:31,885 of goes back to that costing component 393 00:17:31,885 --> 00:17:33,005 and not over provisioning. 394 00:17:33,265 --> 00:17:36,845 So you have access to things like reservations 395 00:17:37,265 --> 00:17:40,165 and being able to do reserve capacity in storage, 396 00:17:40,575 --> 00:17:43,445 which depending on the amount that you're going to, 397 00:17:44,545 --> 00:17:45,885 you know potentially provision 398 00:17:45,885 --> 00:17:47,325 and leverage within your environment, 399 00:17:47,495 --> 00:17:49,765 there could be very real savings for you there 400 00:17:49,785 --> 00:17:53,405 to be in a managed storage offering over something like just 401 00:17:53,495 --> 00:17:56,645 discs which are going to be expensive for you over time. 402 00:17:56,985 --> 00:17:59,205 Either on the management plane to kind 403 00:17:59,205 --> 00:18:01,085 of wrangle things together and get it all wired up 404 00:18:01,085 --> 00:18:03,045 and make sure that hey if it does go away, 405 00:18:03,045 --> 00:18:04,805 how do we restore it and what does that look like? 406 00:18:05,625 --> 00:18:09,005 Or just the general cost of a disc versus 407 00:18:09,805 --> 00:18:13,845 a backend storage service like Azure files. 408 00:18:13,975 --> 00:18:15,845 - Right. And that's the way we started going 409 00:18:15,845 --> 00:18:17,365 with this client is, you know what, 410 00:18:17,365 --> 00:18:19,045 why don't we just do Azure files? 411 00:18:19,185 --> 00:18:21,365 You want it all in Azure anyways. 412 00:18:21,695 --> 00:18:25,605 Kinda like you mentioned with Azure files you only pay for 413 00:18:25,605 --> 00:18:28,565 what you use instead of paying for the fully managed disc 414 00:18:28,745 --> 00:18:31,285 and the capacity that you're doing. 415 00:18:31,945 --> 00:18:33,605 But I think, and here's 416 00:18:33,605 --> 00:18:35,085 what I would say about if you're doing Azure files, 417 00:18:35,085 --> 00:18:36,525 if you're accessing it from Azure files 418 00:18:36,745 --> 00:18:39,325 and then I want maybe we focus a little bit more on Azure 419 00:18:39,325 --> 00:18:41,845 files is the one client I had where it stretch 420 00:18:41,845 --> 00:18:43,925 and you do talk about the hot cash, 421 00:18:44,915 --> 00:18:48,325 this is the biggest issue I have found with Azure files 422 00:18:48,465 --> 00:18:52,445 and then syncing to an on-prem server on-prem servers 423 00:18:53,275 --> 00:18:57,685 have the ability to recognize when a file is changed 424 00:18:57,685 --> 00:18:59,845 or modified and sync it up 425 00:18:59,945 --> 00:19:02,725 to Azure files relatively quickly. 426 00:19:03,085 --> 00:19:05,085 I mean we're talking a few minutes 427 00:19:05,975 --> 00:19:08,205 think OneDrive sync type of functionality. 428 00:19:08,385 --> 00:19:10,485 It recognizes it as they're changed 429 00:19:10,505 --> 00:19:11,645 and synchronizes them up. 430 00:19:11,665 --> 00:19:14,485 Yep. However, what this client has run into is if they're 431 00:19:14,485 --> 00:19:16,245 accessing Azure files and Azure files 432 00:19:16,665 --> 00:19:19,165 and then need to access it from that server, 433 00:19:19,735 --> 00:19:22,445 Azure files does not have that same capability. 434 00:19:22,745 --> 00:19:24,085 It doesn't have, 435 00:19:24,665 --> 00:19:26,325 and I can't remember exactly what it's called, 436 00:19:26,595 --> 00:19:28,605 it's essentially a trigger to know 437 00:19:29,115 --> 00:19:31,565 this file's been modified, it needs to be synchronized, 438 00:19:32,065 --> 00:19:36,085 it relies on a job that runs every 24 hours 439 00:19:36,425 --> 00:19:38,045 to synchronize files down 440 00:19:38,595 --> 00:19:41,405 depending on when you hit like this client was running into 441 00:19:41,405 --> 00:19:43,605 issues where I modified this file 442 00:19:43,605 --> 00:19:45,005 during the day in Azure files 443 00:19:45,785 --> 00:19:49,445 or I modified this file in the evening from Azure files 444 00:19:49,465 --> 00:19:51,525 and went in the next day to the office 445 00:19:51,865 --> 00:19:54,685 and the server did not have the most recent version 446 00:19:55,085 --> 00:19:56,165 'cause that job hadn't run yet. 447 00:19:56,265 --> 00:19:59,005 Yep. So what I've found is if you are in 448 00:19:59,005 --> 00:20:00,885 that synchronized scenario, you really, 449 00:20:01,245 --> 00:20:03,405 I mean I don't wanna say you only should access 'em from the 450 00:20:03,405 --> 00:20:05,525 server, but you kind of need to decide 451 00:20:05,535 --> 00:20:07,645 where you're gonna access these files from. 452 00:20:07,705 --> 00:20:09,525 What's that source of truth 453 00:20:09,865 --> 00:20:10,965 and stick 454 00:20:10,965 --> 00:20:14,245 with only one versus having some people access it from Azure 455 00:20:14,245 --> 00:20:16,525 files and other people access it from the server. 456 00:20:16,905 --> 00:20:19,525 If you find yourself in that synchronized environment, 457 00:20:20,005 --> 00:20:21,525 I haven't found a good solution for it. 458 00:20:21,755 --> 00:20:24,205 I've found some people that like run scripts to try 459 00:20:24,205 --> 00:20:26,325 to trigger that synchronization more often, 460 00:20:27,305 --> 00:20:28,965 set it in an Azure runbook, run 461 00:20:28,965 --> 00:20:31,325 that runbook every 30 minutes every hour 462 00:20:31,585 --> 00:20:33,245 to trigger that job. 463 00:20:33,345 --> 00:20:37,965 But it all feels kind of hack ish to 464 00:20:38,675 --> 00:20:40,685 keep those in sync enough 465 00:20:40,685 --> 00:20:43,085 where you can access files from either location 466 00:20:43,345 --> 00:20:45,965 and not cause a bunch of conflicts. 467 00:20:46,065 --> 00:20:48,205 - It it is so it, it's rough to do that. 468 00:20:48,605 --> 00:20:50,805 I don't know that there's a pit of success 469 00:20:50,805 --> 00:20:53,125 that you fall into if you think about it that way. 470 00:20:53,635 --> 00:20:58,605 It's more about recognizing that change detection does take 471 00:20:59,115 --> 00:21:03,405 some time and in large file shares like large managed 472 00:21:03,405 --> 00:21:07,805 shares, it can actually take longer than once every 473 00:21:07,805 --> 00:21:10,765 24 hours depending on the size of the namespace. 474 00:21:11,305 --> 00:21:12,885 So a a couple of things there. 475 00:21:12,985 --> 00:21:16,325 One is you don't want to be triggering that 476 00:21:16,945 --> 00:21:19,685 change detection PowerShell commandlet 477 00:21:19,815 --> 00:21:21,165 every 30 minutes like that. 478 00:21:21,165 --> 00:21:23,245 Like a, it's more infrastructure you have 479 00:21:23,245 --> 00:21:25,885 to stand up even if it is something like Azure automation 480 00:21:26,965 --> 00:21:31,005 B is, it's the, the way that job works is 481 00:21:31,705 --> 00:21:34,005 it works by enumerating each 482 00:21:34,185 --> 00:21:37,325 and every file that's in your file share. 483 00:21:37,465 --> 00:21:40,245 So if you have a large file share with a large number 484 00:21:40,245 --> 00:21:44,765 of objects, you are going to incur cost to have 485 00:21:44,765 --> 00:21:45,965 that happen right there. 486 00:21:45,965 --> 00:21:48,165 There's a measure of time that's associated 487 00:21:48,165 --> 00:21:50,765 with enumerating all the files in there to detect changes. 488 00:21:51,555 --> 00:21:56,045 There's also just, hey we're basically doing a a a read 489 00:21:56,045 --> 00:21:58,125 or a get on every single file that's out there 490 00:21:58,305 --> 00:21:59,645 and there's transaction charges 491 00:21:59,815 --> 00:22:01,445 associated with that and other things. 492 00:22:01,505 --> 00:22:04,485 So you need to recognize that that limitation exists 493 00:22:04,705 --> 00:22:05,725 and if you're in a world 494 00:22:05,725 --> 00:22:07,805 where you do something like dual home to like 495 00:22:07,805 --> 00:22:10,685 that dual home isn't a great idea, you really do want a home 496 00:22:10,705 --> 00:22:12,485 to one and pick it as the source of truth 497 00:22:13,325 --> 00:22:14,445 probably the file sync server. 498 00:22:14,745 --> 00:22:17,765 So even that, in that case like your Azure hosted clients, 499 00:22:17,905 --> 00:22:20,325 you should really be thinking about like your file server 500 00:22:20,785 --> 00:22:22,645 and the sync group for your file servers. 501 00:22:22,805 --> 00:22:25,645 'cause you can have multiple file sync servers all in the 502 00:22:25,645 --> 00:22:29,005 same sync group and tied back to the same share is, 503 00:22:29,065 --> 00:22:32,565 you should think about those as the kind of management unit 504 00:22:32,585 --> 00:22:33,605 for you and and the place 505 00:22:33,605 --> 00:22:35,165 where clients are going to access things. 506 00:22:35,545 --> 00:22:38,805 So nobody, like once you go down a file sync path 507 00:22:38,805 --> 00:22:41,085 and you're expecting like immediate sync between them, 508 00:22:41,235 --> 00:22:44,325 like don't bother with accessing the managed share . 509 00:22:44,325 --> 00:22:45,765 Like just recognize that that's a thing 510 00:22:45,765 --> 00:22:48,645 and it's, it's not worth you trying to work your way 511 00:22:48,645 --> 00:22:50,845 around like wait for the service to catch up. 512 00:22:51,005 --> 00:22:53,645 I think everybody knows that hey this is a potential 513 00:22:53,645 --> 00:22:56,245 limitation and yeah we'd love to change it over time 514 00:22:56,745 --> 00:22:59,525 but there's a whole bunch of constraints that exist there 515 00:22:59,915 --> 00:23:02,605 that make it, you know, maybe not the most performant thing, 516 00:23:02,635 --> 00:23:05,685 like the way it works today is it's gotta enumerate every 517 00:23:05,715 --> 00:23:08,765 file in your file share and that's a pretty big downer 518 00:23:08,765 --> 00:23:11,045 but if you just put another file sync server up in Azure 519 00:23:11,585 --> 00:23:12,765 say in that case, so you end up 520 00:23:12,765 --> 00:23:15,085 with managed files share Azure files 521 00:23:15,225 --> 00:23:17,245 and then you end up with a file sync server in Azure 522 00:23:17,245 --> 00:23:19,485 that sits in front of that and then in the same sync group 523 00:23:19,485 --> 00:23:21,885 maybe you have like two on-premises places 524 00:23:21,935 --> 00:23:25,245 where you're doing business great those are two more sync 525 00:23:25,245 --> 00:23:26,485 servers that then sit down there 526 00:23:26,485 --> 00:23:28,565 and those three sync servers can all sit in a group, 527 00:23:29,035 --> 00:23:30,205 they can do what they need to do 528 00:23:30,545 --> 00:23:34,165 and everything's kind of hunky hunky dory. 529 00:23:34,625 --> 00:23:36,245 But as soon as you start walking down the path 530 00:23:36,245 --> 00:23:37,405 and you start thinking about like, 531 00:23:37,665 --> 00:23:39,125 oh this client's gonna go here 532 00:23:39,145 --> 00:23:41,685 but this client's gonna access some other thing in a totally 533 00:23:41,685 --> 00:23:44,805 different way like that is not putting yourself into the pit 534 00:23:44,805 --> 00:23:46,805 of success or or a customer into 535 00:23:46,805 --> 00:23:47,925 the pit of success at that point. 536 00:23:48,105 --> 00:23:50,205 And I kind of wish it was called out in the documentation 537 00:23:50,205 --> 00:23:53,045 better, like it's a little bit buried in some 538 00:23:53,045 --> 00:23:54,205 of the FAQs today 539 00:23:54,425 --> 00:23:57,165 and you kind of like don't run into it until you run into it 540 00:23:57,425 --> 00:23:59,365 but it is good to know upfront that 541 00:23:59,555 --> 00:24:01,405 that limitation does exist. 542 00:24:01,675 --> 00:24:04,125 - Yeah. In these FAQs they have things 543 00:24:04,635 --> 00:24:07,245 like if I create it in one location, 544 00:24:07,385 --> 00:24:09,045 how long does it take to sync? 545 00:24:09,705 --> 00:24:12,605 It talks through if the file changes 546 00:24:13,225 --> 00:24:15,885 on two servers at approximately the same time what happens? 547 00:24:16,385 --> 00:24:19,285 But to your point, the fact that all of this type 548 00:24:19,285 --> 00:24:21,525 of stuff is in FAQs versus like 549 00:24:22,145 --> 00:24:24,525 the deployment documentation when you're setting all 550 00:24:24,525 --> 00:24:27,045 of this up, it would be nice if that was a little bit more 551 00:24:27,335 --> 00:24:28,335 - Clear. 552 00:24:28,335 --> 00:24:29,285 I don't know there's a lot of other stuff in front 553 00:24:29,285 --> 00:24:31,645 of you like you have to figure out, you know, 554 00:24:31,645 --> 00:24:35,125 your redundancy needs like even figuring out do I need like 555 00:24:35,125 --> 00:24:38,925 an LRS or a ZRS storage account can be a heavy enough lift 556 00:24:38,925 --> 00:24:40,805 for some customers , you know, 557 00:24:40,885 --> 00:24:42,965 how do I view redundancy in a second region? 558 00:24:43,035 --> 00:24:45,485 Like how many nines are actually important to me? 559 00:24:46,275 --> 00:24:47,285 What does that look like? 560 00:24:47,505 --> 00:24:51,525 Do I require things like additional data protection 561 00:24:51,565 --> 00:24:52,805 capabilities on there? 562 00:24:52,805 --> 00:24:54,965 You know like uh, you know I mentioned like soft deletes 563 00:24:54,965 --> 00:24:57,285 earlier and you know preventing accident deletes 564 00:24:57,285 --> 00:24:58,405 like that's stuff's all great. 565 00:24:59,345 --> 00:25:02,165 You also have anti-malware capabilities 566 00:25:02,425 --> 00:25:05,845 so you can potentially tie in defender for storage 567 00:25:06,405 --> 00:25:08,125 directly into your file share and not have to run 568 00:25:08,125 --> 00:25:11,365 that on your quote unquote like on-premises server. 569 00:25:11,595 --> 00:25:13,445 Like whether that actually lived on-premises 570 00:25:13,445 --> 00:25:16,205 or it was just an Azure VM running in the cloud. 571 00:25:16,435 --> 00:25:18,485 Like how do you view threat detection? 572 00:25:18,875 --> 00:25:20,685 What kind of logging do you need? 573 00:25:21,305 --> 00:25:22,765 What's your identity surface? 574 00:25:23,035 --> 00:25:25,125 Like how do clients access these things? 575 00:25:25,305 --> 00:25:28,565 Oh is it just SMB or is it SMB and NFS? 576 00:25:28,635 --> 00:25:31,965 Like maybe you have needs on that side as well. 577 00:25:31,965 --> 00:25:34,205 Like what does monitoring and operations look for you? 578 00:25:34,205 --> 00:25:36,765 Like there's a whole bunch of other questions to answer 579 00:25:36,825 --> 00:25:39,725 before you get to how does file sync actually work 580 00:25:40,205 --> 00:25:41,365 - that's a good point 581 00:25:41,365 --> 00:25:42,965 and that's where we ended up 582 00:25:42,965 --> 00:25:45,845 with this client was we started having that conversation 583 00:25:46,105 --> 00:25:49,805 and again they were comparing do we do native Azure file 584 00:25:49,805 --> 00:25:53,165 share or do we do a server and create a file share on there? 585 00:25:54,035 --> 00:25:56,485 They're coming from an on-premises environment 586 00:25:57,025 --> 00:26:00,525 and looking to move all of this into the cloud And 587 00:26:00,525 --> 00:26:04,085 that was one of those conversations we started having was 588 00:26:04,865 --> 00:26:08,485 how does authentication work to Azure file share. 589 00:26:08,815 --> 00:26:12,085 Let's say they were like okay let's put the server aside 590 00:26:12,665 --> 00:26:16,525 and let's think through some of this stuff is things 591 00:26:16,525 --> 00:26:18,285 that maybe you run on a server 592 00:26:18,625 --> 00:26:20,885 and you mentioned one, what are we authenticating against? 593 00:26:21,065 --> 00:26:24,965 Are we doing Azure ad, are we doing active directory? 594 00:26:25,665 --> 00:26:29,445 How does that authentication permissioning mapping network 595 00:26:29,545 --> 00:26:32,405 drives, look if you're gonna do Azure files, 596 00:26:32,875 --> 00:26:35,005 what is our backup scenario? 597 00:26:35,345 --> 00:26:37,405 If we have Azure files 598 00:26:37,625 --> 00:26:40,965 and we want to have backups of this data 599 00:26:41,265 --> 00:26:46,045 and we need to retain our data for X number of days, months, 600 00:26:46,295 --> 00:26:48,765 years, et cetera, what does 601 00:26:48,765 --> 00:26:50,685 that look like if we're gonna do Azure files, 602 00:26:51,265 --> 00:26:54,645 you mentioned antivirus typically on a file server you may 603 00:26:54,645 --> 00:26:58,085 have an antivirus agent running for how you're monitoring 604 00:26:58,825 --> 00:27:01,405 all of your other servers and your other endpoints 605 00:27:01,605 --> 00:27:03,165 and users devices and all of those. 606 00:27:04,235 --> 00:27:08,565 What are we doing about antivirus on all of these servers? 607 00:27:08,745 --> 00:27:11,005 And there are a lot of solutions. 608 00:27:11,185 --> 00:27:15,645 You mentioned those like the Microsoft Defender for storage 609 00:27:16,305 --> 00:27:18,205 is some of the benefits of that 610 00:27:18,345 --> 00:27:22,045 and using that for your malware scanning 611 00:27:22,305 --> 00:27:23,405 but then also using it 612 00:27:23,405 --> 00:27:26,485 for extra stuff like sensitive data protection 613 00:27:26,825 --> 00:27:30,805 and different levels of protection 614 00:27:30,805 --> 00:27:32,005 that you can do in Azure files. 615 00:27:32,665 --> 00:27:34,125 But it was interesting 616 00:27:34,125 --> 00:27:37,645 because they also found themselves in that boat of 617 00:27:38,435 --> 00:27:39,965 this is all brand new to us. 618 00:27:40,415 --> 00:27:43,125 We're not using defender for cloud for anything. 619 00:27:43,505 --> 00:27:45,805 We already have antivirus that we want to use. 620 00:27:46,145 --> 00:27:47,645 We already have a backup solution, 621 00:27:47,645 --> 00:27:49,725 we're not using Azure backup for anything yet. 622 00:27:50,065 --> 00:27:51,445 And sitting down 623 00:27:51,465 --> 00:27:53,965 and from their perspective it was a little bit too of 624 00:27:53,995 --> 00:27:55,365 what are we familiar with 625 00:27:56,065 --> 00:28:00,365 and they did find themselves in a bit of a time crunch is 626 00:28:00,905 --> 00:28:02,645 do we wanna go stand up Azure files 627 00:28:02,985 --> 00:28:06,045 but now maybe we have to go pay for Microsoft defender 628 00:28:06,425 --> 00:28:10,045 for storage and now maybe we have to pay for Azure backup 629 00:28:10,265 --> 00:28:14,005 to get our backups and how does our data retention look, 630 00:28:14,005 --> 00:28:17,405 which is a problem we've already solved in our current SMB 631 00:28:17,405 --> 00:28:19,925 share on-prem that we need to move to the cloud. 632 00:28:20,545 --> 00:28:24,805 And really working through that whole discussion of 633 00:28:25,585 --> 00:28:28,765 not just even a feature for feature comparison 634 00:28:28,835 --> 00:28:30,365 between server and Azure files, 635 00:28:30,865 --> 00:28:34,645 but what are those other things that we have 636 00:28:35,185 --> 00:28:36,925 as an organization that we use it 637 00:28:36,925 --> 00:28:39,365 as the organization requirements that we have in 638 00:28:39,625 --> 00:28:42,725 as an organization that we need to adhere to 639 00:28:42,905 --> 00:28:46,205 and account for where this file share ends up landing. 640 00:28:46,525 --> 00:28:49,005 - I think it's tough, like if you're in a time crunch 641 00:28:49,005 --> 00:28:52,085 to figure that stuff out, I, I think I'd be asking a lot 642 00:28:52,085 --> 00:28:55,805 of other questions do along the way like hey you wanna host 643 00:28:55,805 --> 00:29:00,445 this in Azure but you're not familiar with you know maybe 644 00:29:01,135 --> 00:29:03,285 Azure terminology and Azure constructs. 645 00:29:03,285 --> 00:29:04,805 Like I get that you've got a time crunch 646 00:29:05,425 --> 00:29:06,645 but you're gonna have a lot of the 647 00:29:06,645 --> 00:29:07,885 same questions on the other side. 648 00:29:07,955 --> 00:29:10,965 Like so you mentioned, hey we already have backup in place. 649 00:29:11,195 --> 00:29:13,685 Well if you're running that on an Azure vm, 650 00:29:13,905 --> 00:29:16,325 is it supported, is it licensed? 651 00:29:16,505 --> 00:29:18,805 Are you able to run that backup software in Azure? 652 00:29:19,115 --> 00:29:22,725 Same thing for like malware, like a lot of antivirus 653 00:29:22,825 --> 00:29:25,485 and anti-malware, things that run on-prem, 654 00:29:25,795 --> 00:29:27,765 they don't work the same way when they're running on a 655 00:29:27,765 --> 00:29:30,885 hypervisor especially uh, bespoke version 656 00:29:31,305 --> 00:29:33,165 that's sitting in Azure. 657 00:29:33,345 --> 00:29:35,165 Uh, same thing happens in AWS, right? 658 00:29:35,165 --> 00:29:37,725 Like the hypervisors behave in certain ways. 659 00:29:37,835 --> 00:29:39,805 They expect clients to behave in certain ways. 660 00:29:40,115 --> 00:29:43,365 Like you know, you don't wanna put some errant process out 661 00:29:43,365 --> 00:29:46,165 there that's gonna start spiking CPU all of a sudden 662 00:29:46,185 --> 00:29:48,605 and get you evicted for some weird reason right 663 00:29:48,605 --> 00:29:50,965 that you just weren't ready for or 664 00:29:50,985 --> 00:29:52,405 or anything like that along the way. 665 00:29:52,505 --> 00:29:55,645 So at some point you've gotta spend the time 666 00:29:55,705 --> 00:29:57,805 and answer those questions either way you can't just go 667 00:29:57,805 --> 00:30:01,205 like, you know, willy-nilly and stand up a server in Azure 668 00:30:01,205 --> 00:30:03,405 and then roll all your on-prem software onto it 669 00:30:03,405 --> 00:30:05,805 and then think it's gonna work out for you and 670 00:30:05,805 --> 00:30:07,045 and be hunky dory as well. 671 00:30:07,115 --> 00:30:09,485 Like that too is not having you 672 00:30:09,485 --> 00:30:10,645 fall into the pit of success. 673 00:30:10,835 --> 00:30:11,845 - Yeah, it was 674 00:30:12,185 --> 00:30:14,245 and they did, I mean to kinda wrap it up, 675 00:30:14,245 --> 00:30:17,845 they did end up going with a server for now I think it's, 676 00:30:18,145 --> 00:30:20,885 it was a time crunch, it was quick, it'll work for now, 677 00:30:21,305 --> 00:30:25,325 but it also very much opened eyes to 678 00:30:26,065 --> 00:30:29,765 really thinking through maybe there is something in the 679 00:30:29,765 --> 00:30:30,845 future that needs 680 00:30:30,845 --> 00:30:34,365 to go into Azure files maybe in the future we take this 681 00:30:34,385 --> 00:30:36,885 and there is some of what we put in files 682 00:30:36,995 --> 00:30:38,285 that can go into SharePoint 683 00:30:38,585 --> 00:30:40,405 and this is an issue I've run into a lot 684 00:30:40,405 --> 00:30:42,205 where people find themselves in a time crunch. 685 00:30:42,835 --> 00:30:44,485 They really want to do that lift 686 00:30:44,505 --> 00:30:48,725 and shift file dump type of migration from on-prem 687 00:30:48,725 --> 00:30:51,685 to the cloud without really taking the time and sitting down 688 00:30:51,745 --> 00:30:54,165 and thinking through a lot of 689 00:30:54,165 --> 00:30:56,965 what we talked about is does this belong in a server, 690 00:30:56,995 --> 00:30:59,085 does this belong in Azure files, 691 00:30:59,515 --> 00:31:00,965 does this belong in SharePoint 692 00:31:01,305 --> 00:31:03,165 and how do we need 693 00:31:03,165 --> 00:31:05,645 to think about things differently based on 694 00:31:05,645 --> 00:31:06,965 where we're gonna go with these files 695 00:31:07,275 --> 00:31:09,245 because none of them 696 00:31:09,785 --> 00:31:12,125 are an on-premises file server like you're used to. 697 00:31:12,125 --> 00:31:16,365 There's all different limitations, different 698 00:31:16,965 --> 00:31:19,325 constructs, different ways, how you can work with files, 699 00:31:19,795 --> 00:31:21,845 different challenges that you really need 700 00:31:21,845 --> 00:31:24,285 to consider when you are working 701 00:31:24,285 --> 00:31:25,605 through that type of a migration. 702 00:31:25,805 --> 00:31:27,285 - I guess one of the things you can do is there's a bunch 703 00:31:27,285 --> 00:31:29,645 of, you know, kind of like worksheets that you can sit down 704 00:31:29,785 --> 00:31:31,925 and, and you can think about like how to go 705 00:31:31,925 --> 00:31:34,365 through these things on your own and 706 00:31:34,385 --> 00:31:37,165 and start to rationalize some of it even down 707 00:31:37,225 --> 00:31:41,165 to hey should I do the SharePoint thing versus Azure files 708 00:31:41,265 --> 00:31:43,605 versus just you know, SMB share 709 00:31:43,605 --> 00:31:45,165 or something like that and how it comes together. 710 00:31:45,905 --> 00:31:49,085 So I, I'll put a link in the show notes for everybody just 711 00:31:49,265 --> 00:31:52,285 for kind of the all up migration article FRAGER files, 712 00:31:52,695 --> 00:31:56,565 which takes you through some of those considerations like 713 00:31:57,275 --> 00:32:00,245 where's the data coming from, how do your clients access it, 714 00:32:00,745 --> 00:32:03,605 what's the metadata that those clients use? 715 00:32:03,915 --> 00:32:07,165 Like do you use full on NTFS permissions, 716 00:32:07,945 --> 00:32:10,245 do you use some other kind of ? 717 00:32:10,345 --> 00:32:12,925 Do you rely on things like file locks, 718 00:32:12,945 --> 00:32:15,605 you know like global file locks, read-only files. 719 00:32:16,385 --> 00:32:18,805 What's your view on timestamps and how that works? 720 00:32:18,875 --> 00:32:21,325 Like how do you want those to migrate across like think 721 00:32:21,325 --> 00:32:22,365 maybe like created time 722 00:32:22,385 --> 00:32:24,445 and last access time, things like that. 723 00:32:24,945 --> 00:32:28,045 Do you have other non-standard properties 724 00:32:28,195 --> 00:32:30,205 that are potentially associated with those files? 725 00:32:30,275 --> 00:32:34,605 Like are they going to work in a managed share metadata, all 726 00:32:34,605 --> 00:32:36,205 that stuff and even down to like the version 727 00:32:36,265 --> 00:32:39,605 of like Windows server that you potentially run on. 728 00:32:39,605 --> 00:32:42,565 Like if you're presenting SMB shares to clients today, 729 00:32:42,985 --> 00:32:45,925 are you doing that on Windows server 2019? 730 00:32:46,145 --> 00:32:48,125 Are you doing that on Windows server 2022? 731 00:32:48,505 --> 00:32:51,525 Are you doing that on something older like you running like 732 00:32:51,565 --> 00:32:53,445 a really old legacy version of Windows server, 733 00:32:53,515 --> 00:32:56,045 like Windows Server 2012 or something like that? 734 00:32:56,745 --> 00:32:58,205 Are you not even running Windows server? 735 00:32:58,225 --> 00:33:00,765 Are you running Linux and presenting like SMB 736 00:33:00,765 --> 00:33:02,005 shares from Linux clients? 737 00:33:02,075 --> 00:33:04,405 Like how does your environment look today? 738 00:33:04,425 --> 00:33:05,645 How does it manifest and 739 00:33:05,785 --> 00:33:07,765 how can it come across to the other side? 740 00:33:08,175 --> 00:33:10,605 There is this kind of like crawl, walk, run strategy 741 00:33:10,745 --> 00:33:12,965 of hey let's potentially do a lift and shift 742 00:33:12,965 --> 00:33:15,565 and go to a server, maybe look for managed services 743 00:33:16,255 --> 00:33:17,445 later on downstream. 744 00:33:17,785 --> 00:33:20,445 Uh, I think generally like the path to success 745 00:33:20,445 --> 00:33:24,125 with the cloud is trying to get yourself away from servers 746 00:33:24,225 --> 00:33:27,005 and into those managed services as long 747 00:33:27,005 --> 00:33:30,005 as they fit the constraints of your requirements 748 00:33:30,145 --> 00:33:31,645 and they, they might always not fit the 749 00:33:31,645 --> 00:33:32,845 constraints of your requirements. 750 00:33:32,955 --> 00:33:36,365 Like you mentioned, you know, the whole confabulation 751 00:33:36,435 --> 00:33:40,525 with having to figure out sync between a cloud share 752 00:33:40,825 --> 00:33:42,525 and a hot cache server over here 753 00:33:42,525 --> 00:33:45,285 and how that actually manifests within the, the the service. 754 00:33:45,435 --> 00:33:46,645 Like if that stuff doesn't work 755 00:33:46,645 --> 00:33:48,045 for you then it doesn't work for you, right? 756 00:33:48,045 --> 00:33:50,365 Like there, there's a bunch of different ways to get around 757 00:33:50,365 --> 00:33:52,285 that and plan for whatever the next thing is. 758 00:33:56,065 --> 00:33:57,685 - Do you feel overwhelmed by trying 759 00:33:57,685 --> 00:33:59,965 to manage your Office 365 environment? 760 00:34:00,105 --> 00:34:01,845 Are you facing unexpected issues 761 00:34:01,875 --> 00:34:03,725 that disrupt your company's productivity? 762 00:34:03,755 --> 00:34:06,525 Intelligent is here to help much like you take your car 763 00:34:06,525 --> 00:34:08,925 to the mechanic that has specialized knowledge on how 764 00:34:08,925 --> 00:34:12,005 to best keep your car running Intelligent helps you 765 00:34:12,005 --> 00:34:13,725 with your Microsoft cloud environment 766 00:34:13,725 --> 00:34:15,325 because that's their expertise. 767 00:34:15,475 --> 00:34:16,765 Intelligent keeps up 768 00:34:16,765 --> 00:34:18,845 with the latest updates in the Microsoft cloud 769 00:34:18,845 --> 00:34:20,285 to help keep your business running 770 00:34:20,645 --> 00:34:21,805 smoothly and ahead of the curve. 771 00:34:21,875 --> 00:34:23,765 Whether you are a small organization 772 00:34:23,765 --> 00:34:26,045 with just a few users up to an organization 773 00:34:26,045 --> 00:34:29,365 of several thousand employees they want to partner with you 774 00:34:29,425 --> 00:34:32,965 to implement and administer your Microsoft Cloud technology, 775 00:34:33,535 --> 00:34:36,925 visit them at intelligent.com/podcast, 776 00:34:37,425 --> 00:34:41,845 that's I-N-T-E-L-L-I-G-I-N 777 00:34:41,925 --> 00:34:45,485 k.com/podcast for more information 778 00:34:45,505 --> 00:34:47,525 or to schedule a 30 minute call to get started 779 00:34:47,525 --> 00:34:48,565 with them today. 780 00:34:49,405 --> 00:34:52,005 Remember intelligent focuses on the Microsoft cloud 781 00:34:52,145 --> 00:34:53,965 so you can focus on your business 782 00:34:56,385 --> 00:34:59,205 And there are a bunch of those migration guides. 783 00:34:59,265 --> 00:35:01,925 You pulled it up where you're coming from different sources, 784 00:35:01,995 --> 00:35:05,445 whether it's Windows Server 2012, 785 00:35:05,445 --> 00:35:08,365 whether you're coming from a nas, if you're coming from 786 00:35:09,405 --> 00:35:10,925 Linux with SMB 787 00:35:11,065 --> 00:35:13,205 and then are you going into that hybrid deployment 788 00:35:13,225 --> 00:35:15,245 or are you going into a cloud only deployment? 789 00:35:15,795 --> 00:35:19,965 Different recommendations around tools to do it, articles 790 00:35:19,965 --> 00:35:23,245 to walk through how you start thinking through what 791 00:35:23,245 --> 00:35:24,525 that process is 792 00:35:24,995 --> 00:35:28,045 because that's the other thing is based on the amount 793 00:35:28,045 --> 00:35:29,605 of files and where these are going 794 00:35:30,105 --> 00:35:32,685 and how often people are using these files 795 00:35:33,185 --> 00:35:37,045 and constraints around how quickly files can move, 796 00:35:37,595 --> 00:35:39,325 another thing to think about is 797 00:35:39,465 --> 00:35:43,045 how do you get all these files from on-premises to the cloud 798 00:35:43,045 --> 00:35:46,485 or from one location to the other while not losing data 799 00:35:46,485 --> 00:35:47,805 and still allowing people to work. 800 00:35:47,985 --> 00:35:50,765 So there's a lot of different articles guidance 801 00:35:50,765 --> 00:35:54,125 around these in this migration SMB 802 00:35:54,425 --> 00:35:56,925 and the other thing we haven't even touched on is migrating 803 00:35:57,025 --> 00:35:59,845 to NFS Azure file shares 804 00:35:59,845 --> 00:36:01,845 because as your file shares can be SMB 805 00:36:02,185 --> 00:36:07,085 or NFS depending on your needs, which is, 806 00:36:07,605 --> 00:36:09,245 I mean there's so much to think about here Scott, 807 00:36:09,315 --> 00:36:11,845 like we have all these articles we thought about talking 808 00:36:11,845 --> 00:36:14,565 through and I feel like in some respects we've only 809 00:36:14,565 --> 00:36:16,365 scratched the surface of things 810 00:36:16,385 --> 00:36:17,725 to think about in considerations 811 00:36:17,725 --> 00:36:19,085 with these file shares. There 812 00:36:19,085 --> 00:36:20,085 - Is a whole bunch. 813 00:36:20,085 --> 00:36:23,325 So I think with all things it's worth taking the time 814 00:36:23,505 --> 00:36:26,685 to sit down and read the manual, right? 815 00:36:26,685 --> 00:36:29,485 Like go through that. Like I find myself doing that a lot 816 00:36:29,485 --> 00:36:31,285 and you mentioned this like with this customer like hey 817 00:36:31,285 --> 00:36:33,485 they're in a time crunch, they're potentially like bringing 818 00:36:33,505 --> 00:36:36,685 you in for your expertise at some point, you know, no matter 819 00:36:36,685 --> 00:36:37,925 how much expertise like you 820 00:36:37,925 --> 00:36:39,805 or I bring to a customer conversation, 821 00:36:40,265 --> 00:36:41,765 the customers still need to sit down 822 00:36:41,785 --> 00:36:43,685 and digest some of that information for themselves. 823 00:36:43,755 --> 00:36:45,205 Like it's worth it. 824 00:36:45,305 --> 00:36:46,965 You know, if you're somebody who's looking at this stuff 825 00:36:46,965 --> 00:36:48,605 and you're going like, oh my gosh there's you know, 826 00:36:48,605 --> 00:36:50,005 a whole bunch of articles that I need 827 00:36:50,005 --> 00:36:53,085 to read like yeah sorry, like you gotta go read a bunch 828 00:36:53,085 --> 00:36:55,365 of articles, it's gonna take you an hour 829 00:36:55,385 --> 00:36:56,925 to two hours or go watch a video. 830 00:36:57,195 --> 00:36:59,205 Like there's tons of videos on YouTube 831 00:36:59,305 --> 00:37:01,205 and a bunch of other things that can get you like 832 00:37:01,745 --> 00:37:04,885 to the point where you know enough to be dangerous rapidly 833 00:37:05,525 --> 00:37:06,565 and that's 834 00:37:06,565 --> 00:37:07,645 really what you want to be able to do, right? 835 00:37:07,645 --> 00:37:10,605 Like just understand hey I know enough to be dangerous. 836 00:37:10,785 --> 00:37:12,805 You don't have to be like Neo in the nature matrix, right? 837 00:37:12,805 --> 00:37:13,885 Where you get plugged in the first time 838 00:37:13,885 --> 00:37:15,405 and you go like I know kung fu. 839 00:37:15,465 --> 00:37:17,205 You just need to go like, oh yeah, I know how 840 00:37:17,205 --> 00:37:19,885 to put one foot in front of the other great, you know, 841 00:37:19,885 --> 00:37:22,765 let's get you onto the next step along the way. 842 00:37:22,905 --> 00:37:24,045 - Oh this was interesting. 843 00:37:24,345 --> 00:37:28,925 Did you see this, this article that was posted in Discord? 844 00:37:28,925 --> 00:37:31,525 Mm-hmm . So this one Robocop these cloud tier, 845 00:37:31,685 --> 00:37:33,405 I mean this is something else to think about, right? 846 00:37:33,405 --> 00:37:35,845 Because technically when you, 847 00:37:36,525 --> 00:37:40,245 I believe when you copy a file from your server up 848 00:37:40,265 --> 00:37:41,805 to something like data box, 849 00:37:42,345 --> 00:37:44,885 it is gonna update the modified date. 850 00:37:44,885 --> 00:37:49,845 Those files and data box are not the same files as 851 00:37:50,545 --> 00:37:51,565 what's on premises. 852 00:37:51,665 --> 00:37:54,365 So if you try to use something like Robocopy 853 00:37:54,365 --> 00:37:57,205 with a data box, yeah you're absolutely gonna get different 854 00:37:57,445 --> 00:37:58,925 modified dates for those 855 00:37:59,445 --> 00:38:00,445 - . 856 00:38:00,445 --> 00:38:02,245 This is where things like go ahead 857 00:38:02,305 --> 00:38:04,885 and just extoll the virtues of your own products. 858 00:38:05,425 --> 00:38:07,645 So one of the other things that I walk 859 00:38:07,645 --> 00:38:10,565 after is AzCopy, it's near and dear to my heart. 860 00:38:10,595 --> 00:38:13,005 Like I'm, I'm the product manager for AzCopy. 861 00:38:13,305 --> 00:38:15,405 We handle this scenario very, very well. 862 00:38:16,205 --> 00:38:19,485 I know there's this section in the Azure files documentation 863 00:38:19,955 --> 00:38:24,125 that says don't use AZ copy and use robocopy 864 00:38:24,505 --> 00:38:27,965 but it doesn't give you a good answer as to why that is. 865 00:38:28,185 --> 00:38:29,565 And I've been trying to hunt this down 866 00:38:29,565 --> 00:38:30,805 with the file folks for a while. 867 00:38:30,835 --> 00:38:33,085 Like I fundamentally believe that everything 868 00:38:33,085 --> 00:38:35,365 that Robocopy does we do 869 00:38:36,145 --> 00:38:38,725 and we actually probably do it better. 870 00:38:39,225 --> 00:38:40,285 But you're reading an article 871 00:38:40,285 --> 00:38:42,525 that hasn't been updated on docs in years and years 872 00:38:42,525 --> 00:38:45,845 and years that I've just gotta go find the right person to 873 00:38:46,485 --> 00:38:48,445 convince them to convince them to get there. 874 00:38:48,445 --> 00:38:51,325 Like the cool thing about it like easy copy versus something 875 00:38:51,325 --> 00:38:55,645 like a RO robocop or even a data box is we live 876 00:38:55,645 --> 00:38:58,485 and breathe by the Azure files rest API 877 00:38:58,865 --> 00:39:01,045 and what methods are presented back in 878 00:39:01,045 --> 00:39:02,645 that restful API interface. 879 00:39:02,945 --> 00:39:06,565 So we support all those things like preserving file creation 880 00:39:06,595 --> 00:39:09,365 time, preserving last modified times, like all 881 00:39:09,365 --> 00:39:11,365 that stuff just works with something like AZ copy 882 00:39:12,225 --> 00:39:14,965 and it's likely more performant as well. 883 00:39:15,505 --> 00:39:18,165 You know use my fake like dictionary word for the day. Yep. 884 00:39:18,405 --> 00:39:19,485 Robocopy is kind of cool 885 00:39:20,145 --> 00:39:22,125 but it's not multi-threaded in the way 886 00:39:22,125 --> 00:39:24,085 that we are in easy Z copy. 887 00:39:24,235 --> 00:39:26,885 Like we basically built a client to we, 888 00:39:26,885 --> 00:39:29,525 we built a copy client that hogs all the resources 889 00:39:29,785 --> 00:39:31,765 of the client that you run it on 890 00:39:32,025 --> 00:39:33,885 and it's meant to do that like by design, 891 00:39:33,915 --> 00:39:35,885 it's a very resource hungry application 892 00:39:36,385 --> 00:39:37,805 but it's meant to be multithreaded 893 00:39:37,805 --> 00:39:39,805 and just get this stuff done fast 894 00:39:40,345 --> 00:39:42,445 and the right way kind of the first time. 895 00:39:42,905 --> 00:39:46,205 So we support all those scenarios and do all that stuff. 896 00:39:46,315 --> 00:39:50,805 It's on my list for 2024 to go find whichever person 897 00:39:51,385 --> 00:39:53,085 in the files team decided 898 00:39:53,155 --> 00:39:55,765 that we were gonna say easy copy isn't the right tool 899 00:39:55,785 --> 00:39:58,685 for this job and either convince them that it is 900 00:39:59,105 --> 00:40:01,725 or if they're convinced that it's not, I'll go fix 901 00:40:01,725 --> 00:40:03,245 that in easy copy and I'll make it better 902 00:40:03,245 --> 00:40:04,325 than robocopy. That 903 00:40:04,325 --> 00:40:07,805 - Is interesting because this migrate SMB to Azure files, 904 00:40:08,375 --> 00:40:10,685 everything that they have in here 905 00:40:11,225 --> 00:40:13,965 to migrate is all Azure file sync, 906 00:40:14,335 --> 00:40:16,765 Azure data box and robo copy. 907 00:40:17,155 --> 00:40:20,245 They never mention okay an Azure storage mover, 908 00:40:20,245 --> 00:40:21,885 they don't ever mention AC copy in here. 909 00:40:22,115 --> 00:40:24,405 It's also interesting I don't uh see anywhere in here 910 00:40:24,405 --> 00:40:26,085 where they say data box 911 00:40:26,545 --> 00:40:29,445 and robocopy, if you're using databox, 912 00:40:29,465 --> 00:40:33,125 the recommendation is Azure file sync, which again probably 913 00:40:33,885 --> 00:40:37,765 I would think accomplishes that better than Robocop does 914 00:40:37,825 --> 00:40:40,005 and the way it would maybe synchronize those files 915 00:40:40,145 --> 00:40:42,765 and handle that is use databox 916 00:40:43,065 --> 00:40:45,765 to get the bulk of your files. 917 00:40:45,925 --> 00:40:49,045 I mean if you're moving terabytes, petabytes, 918 00:40:49,825 --> 00:40:52,285 my my daughter asked me what starts coming 919 00:40:52,295 --> 00:40:54,565 after you get into like it wasn't bytes 920 00:40:54,565 --> 00:40:57,285 but it was when you start getting up into like numbers 921 00:40:57,375 --> 00:40:58,885 above trillion in quadrillion 922 00:40:58,885 --> 00:41:01,165 and all of those really big numbers. 923 00:41:01,355 --> 00:41:03,445 - Petabytes. Is that Zetabytes? Yeah. 924 00:41:03,445 --> 00:41:05,125 Yeah , . Lots of zeroes 925 00:41:05,385 --> 00:41:08,805 - But once you start getting into those like Azure file sync 926 00:41:08,905 --> 00:41:10,325 or AZ copy 927 00:41:10,345 --> 00:41:12,845 or something like that just is not gonna work due 928 00:41:12,845 --> 00:41:14,565 to the sheer amount of data 929 00:41:14,565 --> 00:41:17,045 and the time it would take where I get it you have 930 00:41:17,045 --> 00:41:21,045 to use a data box but I think that goes back into like 931 00:41:21,045 --> 00:41:24,565 with this person in Reddit was talking about is they use 932 00:41:24,565 --> 00:41:27,765 Databox and robocop technically if you go look at the 933 00:41:27,965 --> 00:41:30,765 documentation that is not any of those recommendations 934 00:41:30,785 --> 00:41:34,005 for Microsoft is to use robocop after databox. 935 00:41:34,235 --> 00:41:36,245 It's always Azure file sync 936 00:41:36,465 --> 00:41:38,445 and if they listen to those podcasts they would know 937 00:41:38,445 --> 00:41:40,405 that they could use AZ copy as well. We 938 00:41:40,405 --> 00:41:42,405 - Should talk about this one maybe at some point too. 939 00:41:42,865 --> 00:41:44,085 Put it on the backlog. Oh 940 00:41:44,105 --> 00:41:45,205 - You just added one. 941 00:41:45,565 --> 00:41:48,125 I want everybody to know that was not me that said that. 942 00:41:48,125 --> 00:41:50,005 That was Scott . Okay, keep going. 943 00:41:50,225 --> 00:41:53,165 - We should talk about online versus offline migrations. 944 00:41:53,595 --> 00:41:56,885 Kind of like the data box versus AZ copy versus 945 00:41:58,085 --> 00:42:00,085 whatever data factory kind of thing. 946 00:42:00,565 --> 00:42:02,005 I think there's a general misconception 947 00:42:02,475 --> 00:42:05,605 that if you have a lot of data that it's gonna be quicker 948 00:42:05,785 --> 00:42:07,405 for you to do something like databox, 949 00:42:07,405 --> 00:42:09,725 like you mentioned like terabyte 950 00:42:09,785 --> 00:42:12,165 to potentially like petabyte scale migration. 951 00:42:13,005 --> 00:42:15,245 I actually wouldn't use a data box for 952 00:42:15,755 --> 00:42:17,565 most petabyte scale migrations. 953 00:42:17,845 --> 00:42:19,405 I would do those as online migrations 954 00:42:19,785 --> 00:42:22,645 and ensure that we have kind of a big enough pipe in place 955 00:42:22,905 --> 00:42:26,845 to, to get all that stuff working and and ready to go. 956 00:42:27,115 --> 00:42:30,405 Like I know there's customers out there who they go like, 957 00:42:30,405 --> 00:42:33,005 oh I've got like 10 terabytes or 20 terabytes 958 00:42:33,005 --> 00:42:34,965 or a hundred terabytes of data and that's a whole bunch. 959 00:42:35,845 --> 00:42:40,005 I work with the other like broad end of customers, 960 00:42:40,035 --> 00:42:42,325 like you're at one end of the spectrum on that side 961 00:42:42,325 --> 00:42:46,125 and I'd argue like potentially like quite small like you 962 00:42:46,125 --> 00:42:47,805 know like we'd rather be working 963 00:42:47,805 --> 00:42:49,605 with like petabyte scale customers 964 00:42:50,105 --> 00:42:52,805 and I've seen customers that even like 965 00:42:52,835 --> 00:42:57,325 with AZ copy they're copying tens of petabytes a week, 966 00:42:57,825 --> 00:42:59,805 you know to Azure for a single workload 967 00:43:00,115 --> 00:43:01,365 just to get those up there. 968 00:43:01,365 --> 00:43:03,285 Like there are workloads that are at that scale 969 00:43:03,285 --> 00:43:04,725 and they're doing online migrations 970 00:43:05,385 --> 00:43:07,645 and they're doing it quite successfully. 971 00:43:08,105 --> 00:43:12,605 So yeah, don't view like Databox as an end all be all a lot 972 00:43:12,605 --> 00:43:14,045 of the time like once you look at it 973 00:43:14,045 --> 00:43:16,205 and you look at like the shipping times and the turnaround 974 00:43:16,345 --> 00:43:17,965 and the potential loss 975 00:43:17,965 --> 00:43:19,605 of fidelity along the way when it comes 976 00:43:19,605 --> 00:43:23,005 to things like metadata that you'd really might want to 977 00:43:23,565 --> 00:43:25,925 consider online migration along the way 978 00:43:25,925 --> 00:43:28,045 and there's a whole bunch of tools particularly 979 00:43:28,045 --> 00:43:30,405 for like Azure files that can potentially get you there 980 00:43:30,705 --> 00:43:32,525 or just for object storage in general. 981 00:43:32,555 --> 00:43:35,485 - Alright. And even though the docs don't recommend AZ copy 982 00:43:35,815 --> 00:43:38,125 Scott, you can take Solace 983 00:43:38,125 --> 00:43:42,365 and the fact that chat GPT recommends using AZ copy , 984 00:43:42,815 --> 00:43:43,815 - There you go. 985 00:43:43,815 --> 00:43:46,205 Like I said, this is on my my 2024 list. 986 00:43:46,365 --> 00:43:47,765 I don't know like a lot 987 00:43:47,765 --> 00:43:50,085 of the files documentation was written kind of like 988 00:43:50,085 --> 00:43:52,365 before my time with AZ copy 989 00:43:53,185 --> 00:43:54,325 and a lot of the things 990 00:43:54,325 --> 00:43:56,725 that they call out like hey you're gonna lose some fidelity. 991 00:43:57,035 --> 00:44:00,325 Like the only way that you lose fidelity is if the rest API 992 00:44:00,325 --> 00:44:03,085 doesn't support something which you know, the rest 993 00:44:03,085 --> 00:44:04,685 of API doesn't support any everything. 994 00:44:04,975 --> 00:44:06,125 There have been gaps there 995 00:44:06,125 --> 00:44:07,685 and we've been kind of pushing the files team 996 00:44:07,785 --> 00:44:09,125 to make those things better 997 00:44:09,125 --> 00:44:11,885 and they have been like they recently introduced OAuth over 998 00:44:11,885 --> 00:44:15,605 rest, so on files rest you can actually do OAuth now, 999 00:44:15,775 --> 00:44:17,365 which is an interesting thing 1000 00:44:17,825 --> 00:44:20,725 and opens up, opens up a whole bunch of broad scenarios 1001 00:44:20,725 --> 00:44:22,085 to like our SDK customers 1002 00:44:22,085 --> 00:44:25,205 and ultimately tools like easy copy or 1003 00:44:25,225 --> 00:44:27,325 or anything like that along the way. 1004 00:44:27,425 --> 00:44:29,485 So yeah, yeah, put it in the backlog. 1005 00:44:29,485 --> 00:44:31,445 We should come back maybe like mid-year 1006 00:44:31,445 --> 00:44:34,205 and talk about online versus offline migrations. 1007 00:44:34,585 --> 00:44:38,165 - Sounds like a plan. We will add it to the list. 1008 00:44:38,735 --> 00:44:40,485 Scott is adding this to the list 1009 00:44:40,625 --> 00:44:42,565 for once instead of me . 1010 00:44:42,785 --> 00:44:44,845 But I think does that wrap us up for today? 1011 00:44:45,365 --> 00:44:46,445 Anything else that likely 1012 00:44:46,515 --> 00:44:48,085 - Does wrap us up for today? 1013 00:44:48,235 --> 00:44:50,045 - Alright, well thank you Scott. 1014 00:44:50,395 --> 00:44:51,925 This is an interesting discussion 1015 00:44:51,945 --> 00:44:54,725 and we didn't even get into comparing this to SharePoint, 1016 00:44:54,735 --> 00:44:57,005 which we do have other podcast episodes. 1017 00:44:57,025 --> 00:44:58,285 If you're curious and more 1018 00:44:58,285 --> 00:45:01,445 of a SharePoint versus Azure files discussion, 1019 00:45:01,545 --> 00:45:03,845 we can go hunt down one of those episodes. 1020 00:45:03,845 --> 00:45:05,325 I don't know that some of the guidance, 1021 00:45:05,325 --> 00:45:06,445 there's changed a whole lot, 1022 00:45:06,545 --> 00:45:09,765 but we'll put that in the show notes if there's a topic you 1023 00:45:09,765 --> 00:45:11,285 want us to dive deeper into. 1024 00:45:11,625 --> 00:45:14,525 We have not done an outstanding job either, Scott, 1025 00:45:14,745 --> 00:45:16,925 of we don't get a ton of listener questions, 1026 00:45:16,925 --> 00:45:18,325 but we haven't always done a great job 1027 00:45:18,325 --> 00:45:19,845 of addressing them timely. 1028 00:45:20,065 --> 00:45:22,365 We should also add that to our 2024 goals 1029 00:45:22,425 --> 00:45:26,085 of if there is a topic someone wants more of a deep dive on 1030 00:45:26,265 --> 00:45:28,645 to let us know and we will 1031 00:45:29,665 --> 00:45:31,685 do a better job than maybe we have in the past 1032 00:45:31,785 --> 00:45:35,285 of addressing those questions and pulling some of those in. 1033 00:45:35,625 --> 00:45:40,365 So you can reach out via probably threads, Mastodon, 1034 00:45:40,905 --> 00:45:43,085 iWatch, Twitter, Scott does not watch Twitter 1035 00:45:43,225 --> 00:45:47,805 or just head over to our website, ms cloud it pro.com 1036 00:45:48,265 --> 00:45:49,805 and look for the contact form 1037 00:45:50,065 --> 00:45:52,485 and send us recommendations there. 1038 00:45:52,745 --> 00:45:54,365 Or if you're one of the members in Discord, 1039 00:45:54,365 --> 00:45:55,965 you can always post stuff there as well. 1040 00:45:56,145 --> 00:45:59,885 But with that Scott, we will wrap up on 1041 00:46:00,105 --> 00:46:02,605 2023 from a live perspective 1042 00:46:02,985 --> 00:46:05,605 and welcome to 2024 to those 1043 00:46:05,605 --> 00:46:07,045 of you listening to the recording. 1044 00:46:07,045 --> 00:46:11,965 Perfect. Thanks Ben. Thanks God, If you enjoyed the podcast, 1045 00:46:12,465 --> 00:46:14,525 go leave us a five star rating in iTunes. 1046 00:46:14,745 --> 00:46:16,085 It helps to get the word out 1047 00:46:16,105 --> 00:46:19,325 so more IT pros can learn about Office 365 and Azure. 1048 00:46:20,105 --> 00:46:22,925 If you have any questions you want us to address on the show 1049 00:46:23,065 --> 00:46:25,485 or feedback about the show, feel free 1050 00:46:25,545 --> 00:46:28,605 to reach out via our website, Twitter, or Facebook. 1051 00:46:28,905 --> 00:46:30,965 Thanks again for listening and have a great day.

Digital Dispatch Podcast Podcast Artwork Image

Microsoft Cloud IT Pro Podcast

Ben Stegink, Scott Hoag

On the MS Cloud IT Pro Podcast, Scott and Ben discuss the Microsoft Cloud with a focus on IT Pros. They'll discuss the latest in Microsoft 365 and Office 365 News, Azure news and talk about their experiences with managing the Microsoft Cloud as well as interview industry experts on various cloud technology. They'll cover things such as SharePoint, Exchange, Microsoft Teams, PowerShell, Azure, Azure AD, Security, Networking, Storage, and the many other technologies and products that have made their way into the Microsoft 365 suite and Azure. To stay up-to-date on the latest in Microsoft Cloud news and gain some valuable knowledge as you deploy it within your own organization, make sure to tune in every week! Find out more at msclouditpropodcast.com.

Contact Show