- Welcome to episode 367 of the Microsoft Cloud IT Pro Podcast recorded live on December 29th, 2023. This is a show about Microsoft 365 and dasher from the perspective of it pros at end users where we discuss a topic or recent news and how it relates to you to kick off the new year. We start out talking about some changes coming to the podcast in 2024. After that, we dive into hosting file shares on Azure and some things to consider.
We briefly touch on comparing this to SharePoint, but then spend the bulk of our time on a hosted Azure server with an SMB share or using Azure storage in the file share functionality of that service. Oh, we made it Scott, our last recording of 2023, our - Last recording of 2023. And it's gonna be our first recording of 2024. Yes. - Because we are live with those Discord members in 2023 and this will come out.
So we didn't talk about this, Scott, and this is a good segue maybe is this is, I'm assuming, going to come out January, six days from now. Four, five, - Something like that. - Thursday, - It should be January four, Thursday the fourth. - Yes. And then you and I, so we do this every once in a while. We'll go out for breakfast, out for coffee and discuss Podcasty stuff and what we wanna do and what we're going to do.
And we went out for coffee a week or so ago, right before the Christmas holiday and discussed the podcast in 2024. And as such, are going to make some changes going into 2024. - Yeah, real quick, let's, let's get through this. So, all right, this will be episode 367 when it comes out. So if you do some quick back of the napkin math, that's at least one episode a week for the past seven years. Give, give or take, we're like six and a half pluses coming on seven.
Sometimes we've released more episodes. - Yeah, I think March will be seven. - Yeah. During conferences and things like that. But it's been a while. Like we've been on this kind of continuous march to, to get this thing out the door. So in 2024 we're going to do that and we're absolutely gonna keep it going, but we are going to change a few things up.
So first is, you and I kind of both talked about this and we wanna get back into deeper dives on specific areas either you know, that could be like a service in Azure, could be a new, you know, component that's released in the Microsoft 365 stack, something like that. But I think we like taking deeper dives on things and generally that's like where we'd want to land and we'll still deal the occasional like broader tech space, random news thing, but that should be far less frequent.
Like we do wanna be a little bit more kind of focused on what we're putting out there. Second is, like I said, we've released at least, at least one episode a week for almost seven years straight. Some weeks, especially during conferences, we've cranked out multiple episodes. I remember like Ignite one year we did like 10 or 13 episodes like that, like something crazy that was nuts. It all takes its toll. Burnout is definitely a real thing. You and I have talked a bunch about it.
We both love putting this podcast together and figuring out the content, what to chat about each week and to go through that and, and you know, thanks to everyone who listens and puts up with it, but you know, you and I both need to be mindful of our mental health, certainly like where we are in our respective careers. And I think realistic just about the amount of time we spend on what's ultimately something that like you and I do for our enjoyment. Yep. We don't do this for any monetary gain.
Like if people think that oh you've got memberships and you make money off that, or you've got a YouTube channel and maybe you make money over there, like we don't, we spend money, we don't make any money. We, we in fact lose a bunch on that. So with that all in mind, we're just gonna be cutting back to one episode every other week. So the intention here is to put out more quality content.
So we wanna get back into those deep dives, do more interviews, ultimately be more intentional and less of what's on our mind in the moment. So I, I hope that kind of works out and comes across. And then third is we've been dual releasing to both the podcast site. So that comes out in your podcaster of choice. Could be like Apple Podcasts, could be Spotify, Google Podcasts, YouTube, any, anything like that. And we've been pushing to YouTube video at the same time.
I think we've been a little lax on the YouTube side. So for any viewers that are coming in that way, we're gonna be working on some new things there. We wanna incorporate more of what we're talking about directly into the recordings and hopefully bring everyone all around on kind of all sides, a better all around experience. So with that out of the way you want to get into today's episode, sure. - Okay. So no one more thing.
And I think with a YouTube thing too, and this was something that some members brought up in Discord, Scott, was when we're recording these in the past it's always just been talking heads, right? It's been yours and i's heads for those people that watch in Discord, they just see us. For those of you that watched on YouTube, it was just us. Uh, we are going to be starting to play around with actually doing, showing the screen when we're doing these.
So if you are watching in Discord, you'll see maybe some of the articles that we're referencing. It's not necessarily gonna be demoing things, but as we look at different articles referenced different things, trying to highlight those. And I think this will also help if you do wanna go watch afterwards on YouTube doing some YouTube clips again, different things we'll play with with there.
We're going to start trying to incorporate a little bit more of a visual aspect for those of you that are interested but still not take away from the audio. Still make sure we're explaining things in detail, talking through things. For those of you that still wanna listen to audio. So as we go into 2024, it might bear with us as we figure out some of that balance to really create this in a way that it works for both audiences a little bit better. Yeah. - Yes. See where it all goes. We're open
to feedback too. Let us know. - Yes, absolutely end with that. Let's dive into it now Scott, with our first deep dive ish topic. Deep dive of 2024. And this is one, oh, were you gonna say something? I was gonna say this is one that came out of a client discussion that I have had in the last couple of weeks. It was interesting to talk through this.
And this is around a topic that we have talked about on several occasions in different capacities around where you put your files in the cloud and the particular client discussion started with SharePoint and wanting to put all their files in SharePoint from a file share. And then their plan was just to map the SharePoint site as a network drive.
So they'd still have their network drive, they'd still do that, but the files would just be in SharePoint and brought up the fact that web daf, which is the technology behind it, is now deprecated. Some of that even relies on Internet Explorer, which is now gone. And that quickly pivoted to, okay, so maybe SharePoint isn't the best place, we should still do a file share.
Which resulted in an interesting conversation of do we do Azure files or do we stand up a 20 22, 20 19 server in Azure and do a typical SMB share from this Azure server.
And so we landed on today, well let's talk about this around Azure files deployment, maybe even some comparison between doing Azure files and an Azure server and what those thoughts are and maybe some of the pros and cons, some of the parts of this customer discussion that came up around the decision that they made, which I can share at some point in time as well. - I think it's always an interesting conversation.
So anything that starts outta my head with Azure files versus, and you mentioned versus something like just a traditional Windows server that's maybe out there and it sounded like it could have been even like an Azure hosted Windows server with just an SMB share presented from it. Like in the back of my head immediately I hear that, I'm like, why not do both , you can really have kind of the best of all worlds here if that's a path that you potentially willing to go down.
So like if your requirement is SMB shares Azure files is interesting in that it's a kind of managed service for you. It's a, it's a managed storage service and you can access those files that are in that managed share in multiple ways. So you can do that by directly mounting and directly attaching to that file share that's in Azure, like just in a storage account. You know, there's considerations for networking there. You need line of sight from clients to servers, all those kinds of things.
The other interesting thing that you can potentially do is, and Azure files is uniquely suited for this, is you confront Azure files with what's called a Azure file sync server. It's effectively a cash but it's a near cache and it's a hot cache that can sit closer to your clients and not just sit closer to your clients but potentially give your clients other functionality as well. So there's things that like the managed service might not be able to do.
One of the ones that comes to mind for me off the top of my head is quick QUIC and being able to do SMB over quick. That's something that's relatively new-ish in Windows server, but it only exists in Windows server. It doesn't exist inside of Azure files, the managed service yet.
But because Azure files has this Azure file sync server that can sit in front of it, you can kind of enjoy the benefits of a managed service, managed storage and kind of that provisioned unit of storage that sits behind things and all the capabilities that come along with that. Be it redundancy, data protection, anything like that.
And then you can also front it with what's fundamentally just a traditional SMB server and do everything off of that and get the advantages of things like SMB over quick for your clients as well. So you don't have to worry about maybe something like, oh let me stand up a server, let me provision some disks, let me stripe a bunch of disks together. Maybe I build out a storage pool and then I create an SMB share. I do DFS namespace and present a share out of A DFS namespace back to my clients.
Like it's more just, Hey, I'm gonna stand up a server, I'm gonna put SMB in front of it and rather than presenting back to local disk, I'm just gonna do a direct amount of my Azure file share or do Azure file sync into that and then have those components come back to your clients. It's kind of like the best of both worlds if you're looking for things like high availability, potentially better disaster recovery, you're looking for richer data protection features within your stack.
So things like soft delete for accidental data protection comes to mind for me there you can turn on soft delete you, you've got managed Azure resources, you do Azure resource locks, all that kind of stuff. Or managed shares also are supported with vaulted backup. So you can do backups into something like Azure backup as well and then just kind of get all that wired up and running. So I don't know, like for me it's not a if this or that. It's more like hey, which one of these should you do?
And then should you maybe do both of them together? Because there's, there are some real advantages for you there. - So I'm curious your thoughts. I have mixed feelings on doing both of them. I have one client that does both, that sometimes accesses files from Azure files directly, sometimes accesses them from the server. They have an on-premises server. They have run into some challenges with that, particularly in the frequency that Azure files sync happens.
So I think there's some scenarios to think through there when you're comparing a both or comparing which one is, I would say, where are you accessing these files from and then where's your server sitting? And then I'm also curious on your thoughts of like benefits of Azure files in the cloud.
And I know you mentioned some things like Azure backup and stuff, but you can also backup a VM and Azure is, is there a real advantage that you see when it comes to Azure files in the cloud and doing a server with a file share in the cloud or is this a little bit more of a that stretch type scenario? You have an on-premises server, you want the speed of the on-premises server when you're on-premises and you wanna do some of that backup, that redundancy et cetera up to a file share in Azure.
I think some of those are, and not the discussions that I went to in this client, they were going to go one way or the other. They weren't necessarily looking for that environment and they were emphatic that everything was gonna be in Azure. They were getting rid of all their on-prem servers . And that was a discussion I started having with them was it never even approached the do we do both at what's always, do we do one or do we do the other
because whatever we do is gonna sit in Azure. I - Think it's where you have to do a little bit of that TCO analysis. So one of the things that comes to mind immediately for me is if you're talking about things like it's all in Azure anyway, right? It's, it's a virtual machine. Virtual machines have disks associated with them so you're gonna need to probably bring in some data discs Yep. To actually host the data and get that in. So data disks are like a managed disk in Azure.
Say you did like a premium V two disc, like whatever it is, it really doesn't matter for the most part. Every single one of them is pay for what you provision, not pay for what you use. So you're gonna go ahead and maybe bring in say 128 gig disc or 2 56 you're bringing a terabyte here, a terabyte there, whatever it is, you're potentially overpaying. So one of the TCO things is with Azure files you can set up your shares at potentially smaller sizes and just grow them over time.
Like you don't need to stand up a new disc, you don't need to migrate data between them, anything like that. Like it's just a share that you attach to and you don't have to over-provision on day one. So I think that's kind of an important TCO consideration for you is just what you're putting together and what you're doing there. The other piece is you know resiliency on the backend.
So if you think about a managed disc, you can have a disc that you know ultimately the end of the day like a disc has to live in the same zone as your vm. Like yeah I get their ZRS discs and things like that but still they really home to like a single data center within a region. So if you're looking for additional resiliency redundancy on the storage plane for those things, that's all just included in Azure files because it's just a standard storage account.
So you can do things like locally redundant storage, you can do zone redundant storage, you can even do geo replicated stuff. So if you want to do GRS or GZRS, that's all available to you. And then you get kind of multiple flavors of potentially IOPS and and performance with things like premium versus standard along along the way. I also see a lot of customers like this discussion comes up quite a bit.
Like I don't work in with a lot of our files customers directly 'cause I'm more on the object side. But one of the things that always comes up is how can they use things like replication technologies like DFSR and stand that up and do they use that in their on-prem environments today and how does that translate to the cloud? Well the cool thing is it's just one managed share 'cause all your data can live in that chair.
It has all the data protection features, redundancy, resiliency, all that good kind of stuff. And then you can just front it with those file syncs wherever you want. So you could front it with a file sync server that's hosted in Azure in the case of maybe this customer that you're coming to talking to today or maybe it's a customer who really does have on-prem needs and cloud needs and you could have a file sync server that's in Azure and both on premises back closer to those clients.
So having that hot cache component there I think is is important to you. You know I mentioned Azure backup having like off effectively like offsite backup for these kinds of things is something that you would have to wire up and do yourself like sure it's a virtual machine and maybe you tie that into Azure backup. Is it going to offer you the consistency model that you're looking for? Is it application consistent? Is it crash consistent?
Like what's the consistency model and are you gonna be able to restore it and get it back together versus just having it in a managed share and then you know, if the VM goes away, who cares? I just spin up another VM and and my Azure, you know file share is still sitting there and then you know the last thing on TCO is it kind of goes back to that costing component and not over provisioning.
So you have access to things like reservations and being able to do reserve capacity in storage, which depending on the amount that you're going to, you know potentially provision and leverage within your environment, there could be very real savings for you there to be in a managed storage offering over something like just discs which are going to be expensive for you over time.
Either on the management plane to kind of wrangle things together and get it all wired up and make sure that hey if it does go away, how do we restore it and what does that look like? Or just the general cost of a disc versus a backend storage service like Azure files. - Right. And that's the way we started going with this client is, you know what, why don't we just do Azure files? You want it all in Azure anyways.
Kinda like you mentioned with Azure files you only pay for what you use instead of paying for the fully managed disc and the capacity that you're doing.
But I think, and here's what I would say about if you're doing Azure files, if you're accessing it from Azure files and then I want maybe we focus a little bit more on Azure files is the one client I had where it stretch and you do talk about the hot cash, this is the biggest issue I have found with Azure files and then syncing to an on-prem server on-prem servers have the ability to recognize when a file is changed or modified and sync it up to Azure files relatively quickly.
I mean we're talking a few minutes think OneDrive sync type of functionality. It recognizes it as they're changed and synchronizes them up. Yep. However, what this client has run into is if they're accessing Azure files and Azure files and then need to access it from that server, Azure files does not have that same capability.
It doesn't have, and I can't remember exactly what it's called, it's essentially a trigger to know this file's been modified, it needs to be synchronized, it relies on a job that runs every 24 hours to synchronize files down depending on when you hit like this client was running into issues where I modified this file during the day in Azure files or I modified this file in the evening from Azure files and went in the next day to the office and the server did not have the most recent version
'cause that job hadn't run yet. Yep. So what I've found is if you are in that synchronized scenario, you really, I mean I don't wanna say you only should access 'em from the server, but you kind of need to decide where you're gonna access these files from. What's that source of truth and stick with only one versus having some people access it from Azure files and other people access it from the server. If you find yourself in that synchronized environment, I haven't found a good solution for it.
I've found some people that like run scripts to try to trigger that synchronization more often, set it in an Azure runbook, run that runbook every 30 minutes every hour to trigger that job. But it all feels kind of hack ish to keep those in sync enough where you can access files from either location and not cause a bunch of conflicts. - It it is so it, it's rough to do that. I don't know that there's a pit of success that you fall into if you think about it that way.
It's more about recognizing that change detection does take some time and in large file shares like large managed shares, it can actually take longer than once every 24 hours depending on the size of the namespace. So a a couple of things there. One is you don't want to be triggering that change detection PowerShell commandlet every 30 minutes like that.
Like a, it's more infrastructure you have to stand up even if it is something like Azure automation B is, it's the, the way that job works is it works by enumerating each and every file that's in your file share. So if you have a large file share with a large number of objects, you are going to incur cost to have that happen right there. There's a measure of time that's associated with enumerating all the files in there to detect changes.
There's also just, hey we're basically doing a a a read or a get on every single file that's out there and there's transaction charges associated with that and other things. So you need to recognize that that limitation exists and if you're in a world where you do something like dual home to like that dual home isn't a great idea, you really do want a home to one and pick it as the source of truth probably the file sync server.
So even that, in that case like your Azure hosted clients, you should really be thinking about like your file server and the sync group for your file servers. 'cause you can have multiple file sync servers all in the same sync group and tied back to the same share is, you should think about those as the kind of management unit for you and and the place where clients are going to access things.
So nobody, like once you go down a file sync path and you're expecting like immediate sync between them, like don't bother with accessing the managed share . Like just recognize that that's a thing and it's, it's not worth you trying to work your way around like wait for the service to catch up.
I think everybody knows that hey this is a potential limitation and yeah we'd love to change it over time but there's a whole bunch of constraints that exist there that make it, you know, maybe not the most performant thing, like the way it works today is it's gotta enumerate every file in your file share and that's a pretty big downer but if you just put another file sync server up in Azure say in that case, so you end up with managed files share Azure files
and then you end up with a file sync server in Azure that sits in front of that and then in the same sync group maybe you have like two on-premises places where you're doing business great those are two more sync servers that then sit down there and those three sync servers can all sit in a group, they can do what they need to do and everything's kind of hunky hunky dory.
But as soon as you start walking down the path and you start thinking about like, oh this client's gonna go here but this client's gonna access some other thing in a totally different way like that is not putting yourself into the pit of success or or a customer into the pit of success at that point.
And I kind of wish it was called out in the documentation better, like it's a little bit buried in some of the FAQs today and you kind of like don't run into it until you run into it but it is good to know upfront that that limitation does exist. - Yeah. In these FAQs they have things like if I create it in one location, how long does it take to sync? It talks through if the file changes on two servers at approximately the same time what happens?
But to your point, the fact that all of this type of stuff is in FAQs versus like the deployment documentation when you're setting all of this up, it would be nice if that was a little bit more - Clear. I don't know there's a lot of other stuff in front of you like you have to figure out, you know, your redundancy needs like even figuring out do I need like an LRS or a ZRS storage account can be a heavy enough lift for some customers , you know, how do I view redundancy in a second region?
Like how many nines are actually important to me? What does that look like? Do I require things like additional data protection capabilities on there? You know like uh, you know I mentioned like soft deletes earlier and you know preventing accident deletes like that's stuff's all great. You also have anti-malware capabilities so you can potentially tie in defender for storage directly into your file share and not have to run that on your quote unquote like on-premises server.
Like whether that actually lived on-premises or it was just an Azure VM running in the cloud. Like how do you view threat detection? What kind of logging do you need? What's your identity surface? Like how do clients access these things? Oh is it just SMB or is it SMB and NFS? Like maybe you have needs on that side as well. Like what does monitoring and operations look for you?
Like there's a whole bunch of other questions to answer before you get to how does file sync actually work - that's a good point and that's where we ended up with this client was we started having that conversation and again they were comparing do we do native Azure file share or do we do a server and create a file share on there?
They're coming from an on-premises environment and looking to move all of this into the cloud And that was one of those conversations we started having was how does authentication work to Azure file share. Let's say they were like okay let's put the server aside and let's think through some of this stuff is things that maybe you run on a server and you mentioned one, what are we authenticating against? Are we doing Azure ad, are we doing active directory?
How does that authentication permissioning mapping network drives, look if you're gonna do Azure files, what is our backup scenario?
If we have Azure files and we want to have backups of this data and we need to retain our data for X number of days, months, years, et cetera, what does that look like if we're gonna do Azure files, you mentioned antivirus typically on a file server you may have an antivirus agent running for how you're monitoring all of your other servers and your other endpoints and users devices and all of those. What are we doing about antivirus on all of these servers? And there are a lot of solutions.
You mentioned those like the Microsoft Defender for storage is some of the benefits of that and using that for your malware scanning but then also using it for extra stuff like sensitive data protection and different levels of protection that you can do in Azure files. But it was interesting because they also found themselves in that boat of this is all brand new to us. We're not using defender for cloud for anything. We already have antivirus that we want to use.
We already have a backup solution, we're not using Azure backup for anything yet.
And sitting down and from their perspective it was a little bit too of what are we familiar with and they did find themselves in a bit of a time crunch is do we wanna go stand up Azure files but now maybe we have to go pay for Microsoft defender for storage and now maybe we have to pay for Azure backup to get our backups and how does our data retention look, which is a problem we've already solved in our current SMB share on-prem that we need to move to the cloud.
And really working through that whole discussion of not just even a feature for feature comparison between server and Azure files, but what are those other things that we have as an organization that we use it as the organization requirements that we have in as an organization that we need to adhere to and account for where this file share ends up landing.
- I think it's tough, like if you're in a time crunch to figure that stuff out, I, I think I'd be asking a lot of other questions do along the way like hey you wanna host this in Azure but you're not familiar with you know maybe Azure terminology and Azure constructs. Like I get that you've got a time crunch but you're gonna have a lot of the same questions on the other side. Like so you mentioned, hey we already have backup in place.
Well if you're running that on an Azure vm, is it supported, is it licensed? Are you able to run that backup software in Azure? Same thing for like malware, like a lot of antivirus and anti-malware, things that run on-prem, they don't work the same way when they're running on a hypervisor especially uh, bespoke version that's sitting in Azure. Uh, same thing happens in AWS, right? Like the hypervisors behave in certain ways. They expect clients to behave in certain ways.
Like you know, you don't wanna put some errant process out there that's gonna start spiking CPU all of a sudden and get you evicted for some weird reason right that you just weren't ready for or or anything like that along the way.
So at some point you've gotta spend the time and answer those questions either way you can't just go like, you know, willy-nilly and stand up a server in Azure and then roll all your on-prem software onto it and then think it's gonna work out for you and and be hunky dory as well. Like that too is not having you fall into the pit of success.
- Yeah, it was and they did, I mean to kinda wrap it up, they did end up going with a server for now I think it's, it was a time crunch, it was quick, it'll work for now, but it also very much opened eyes to really thinking through maybe there is something in the future that needs to go into Azure files maybe in the future we take this and there is some of what we put in files that can go into SharePoint and this is an issue I've run into a lot where people find themselves in a time crunch.
They really want to do that lift and shift file dump type of migration from on-prem to the cloud without really taking the time and sitting down and thinking through a lot of what we talked about is does this belong in a server, does this belong in Azure files, does this belong in SharePoint and how do we need to think about things differently based on where we're gonna go with these files because none of them are an on-premises file server like you're used to.
There's all different limitations, different constructs, different ways, how you can work with files, different challenges that you really need to consider when you are working through that type of a migration.
- I guess one of the things you can do is there's a bunch of, you know, kind of like worksheets that you can sit down and, and you can think about like how to go through these things on your own and and start to rationalize some of it even down to hey should I do the SharePoint thing versus Azure files versus just you know, SMB share or something like that and how it comes together.
So I, I'll put a link in the show notes for everybody just for kind of the all up migration article FRAGER files, which takes you through some of those considerations like where's the data coming from, how do your clients access it, what's the metadata that those clients use? Like do you use full on NTFS permissions, do you use some other kind of ? Do you rely on things like file locks, you know like global file locks, read-only files. What's your view on timestamps and how that works?
Like how do you want those to migrate across like think maybe like created time and last access time, things like that. Do you have other non-standard properties that are potentially associated with those files? Like are they going to work in a managed share metadata, all that stuff and even down to like the version of like Windows server that you potentially run on. Like if you're presenting SMB shares to clients today, are you doing that on Windows server 2019?
Are you doing that on Windows server 2022? Are you doing that on something older like you running like a really old legacy version of Windows server, like Windows Server 2012 or something like that? Are you not even running Windows server? Are you running Linux and presenting like SMB shares from Linux clients? Like how does your environment look today? How does it manifest and how can it come across to the other side?
There is this kind of like crawl, walk, run strategy of hey let's potentially do a lift and shift and go to a server, maybe look for managed services later on downstream. Uh, I think generally like the path to success with the cloud is trying to get yourself away from servers and into those managed services as long as they fit the constraints of your requirements and they, they might always not fit the constraints of your requirements.
Like you mentioned, you know, the whole confabulation with having to figure out sync between a cloud share and a hot cache server over here and how that actually manifests within the, the the service. Like if that stuff doesn't work for you then it doesn't work for you, right? Like there, there's a bunch of different ways to get around that and plan for whatever the next thing is. - Do you feel overwhelmed by trying to manage your Office 365 environment?
Are you facing unexpected issues that disrupt your company's productivity? Intelligent is here to help much like you take your car to the mechanic that has specialized knowledge on how to best keep your car running Intelligent helps you with your Microsoft cloud environment because that's their expertise. Intelligent keeps up with the latest updates in the Microsoft cloud to help keep your business running smoothly and ahead of the curve.
Whether you are a small organization with just a few users up to an organization of several thousand employees they want to partner with you to implement and administer your Microsoft Cloud technology, visit them at intelligent.com/podcast, that's I-N-T-E-L-L-I-G-I-N k.com/podcast for more information or to schedule a 30 minute call to get started with them today.
Remember intelligent focuses on the Microsoft cloud so you can focus on your business And there are a bunch of those migration guides. You pulled it up where you're coming from different sources, whether it's Windows Server 2012, whether you're coming from a nas, if you're coming from Linux with SMB and then are you going into that hybrid deployment or are you going into a cloud only deployment?
Different recommendations around tools to do it, articles to walk through how you start thinking through what that process is because that's the other thing is based on the amount of files and where these are going and how often people are using these files and constraints around how quickly files can move, another thing to think about is how do you get all these files from on-premises to the cloud or from one location to the other while not losing data and still allowing people to work.
So there's a lot of different articles guidance around these in this migration SMB and the other thing we haven't even touched on is migrating to NFS Azure file shares because as your file shares can be SMB or NFS depending on your needs, which is, I mean there's so much to think about here Scott, like we have all these articles we thought about talking through and I feel like in some respects we've only scratched the surface of things to think about in considerations
with these file shares. There - Is a whole bunch. So I think with all things it's worth taking the time to sit down and read the manual, right?
Like go through that. Like I find myself doing that a lot and you mentioned this like with this customer like hey they're in a time crunch, they're potentially like bringing you in for your expertise at some point, you know, no matter how much expertise like you or I bring to a customer conversation, the customers still need to sit down and digest some of that information for themselves. Like it's worth it.
You know, if you're somebody who's looking at this stuff and you're going like, oh my gosh there's you know, a whole bunch of articles that I need to read like yeah sorry, like you gotta go read a bunch of articles, it's gonna take you an hour to two hours or go watch a video. Like there's tons of videos on YouTube and a bunch of other things that can get you like to the point where you know enough to be dangerous rapidly and that's really what you want to be able to do, right?
Like just understand hey I know enough to be dangerous. You don't have to be like Neo in the nature matrix, right? Where you get plugged in the first time and you go like I know kung fu. You just need to go like, oh yeah, I know how to put one foot in front of the other great, you know, let's get you onto the next step along the way. - Oh this was interesting. Did you see this, this article that was posted in Discord?
Mm-hmm . So this one Robocop these cloud tier, I mean this is something else to think about, right? Because technically when you, I believe when you copy a file from your server up to something like data box, it is gonna update the modified date. Those files and data box are not the same files as what's on premises. So if you try to use something like Robocopy with a data box, yeah you're absolutely gonna get different modified dates for those - .
This is where things like go ahead and just extoll the virtues of your own products. So one of the other things that I walk after is AzCopy, it's near and dear to my heart. Like I'm, I'm the product manager for AzCopy. We handle this scenario very, very well. I know there's this section in the Azure files documentation that says don't use AZ copy and use robocopy but it doesn't give you a good answer as to why that is. And I've been trying to hunt this down with the file folks for a while.
Like I fundamentally believe that everything that Robocopy does we do and we actually probably do it better. But you're reading an article that hasn't been updated on docs in years and years and years that I've just gotta go find the right person to convince them to convince them to get there.
Like the cool thing about it like easy copy versus something like a RO robocop or even a data box is we live and breathe by the Azure files rest API and what methods are presented back in that restful API interface. So we support all those things like preserving file creation time, preserving last modified times, like all that stuff just works with something like AZ copy and it's likely more performant as well. You know use my fake like dictionary word for the day. Yep.
Robocopy is kind of cool but it's not multi-threaded in the way that we are in easy Z copy. Like we basically built a client to we, we built a copy client that hogs all the resources of the client that you run it on and it's meant to do that like by design, it's a very resource hungry application but it's meant to be multithreaded and just get this stuff done fast and the right way kind of the first time. So we support all those scenarios and do all that stuff.
It's on my list for 2024 to go find whichever person in the files team decided that we were gonna say easy copy isn't the right tool for this job and either convince them that it is or if they're convinced that it's not, I'll go fix that in easy copy and I'll make it better than robocopy. That - Is interesting because this migrate SMB to Azure files, everything that they have in here to migrate is all Azure file sync, Azure data box and robo copy.
They never mention okay an Azure storage mover, they don't ever mention AC copy in here. It's also interesting I don't uh see anywhere in here where they say data box and robocopy, if you're using databox, the recommendation is Azure file sync, which again probably I would think accomplishes that better than Robocop does and the way it would maybe synchronize those files and handle that is use databox to get the bulk of your files.
I mean if you're moving terabytes, petabytes, my my daughter asked me what starts coming after you get into like it wasn't bytes but it was when you start getting up into like numbers above trillion in quadrillion and all of those really big numbers. - Petabytes. Is that Zetabytes? Yeah.
Yeah , . Lots of zeroes - But once you start getting into those like Azure file sync or AZ copy or something like that just is not gonna work due to the sheer amount of data and the time it would take where I get it you have to use a data box but I think that goes back into like with this person in Reddit was talking about is they use Databox and robocop technically if you go look at the documentation that is not any of those recommendations for Microsoft is to use robocop after databox.
It's always Azure file sync and if they listen to those podcasts they would know that they could use AZ copy as well. We - Should talk about this one maybe at some point too. Put it on the backlog. Oh - You just added one. I want everybody to know that was not me that said that. That was Scott . Okay, keep going. - We should talk about online versus offline migrations. Kind of like the data box versus AZ copy versus whatever data factory kind of thing.
I think there's a general misconception that if you have a lot of data that it's gonna be quicker for you to do something like databox, like you mentioned like terabyte to potentially like petabyte scale migration. I actually wouldn't use a data box for most petabyte scale migrations. I would do those as online migrations and ensure that we have kind of a big enough pipe in place to, to get all that stuff working and and ready to go.
Like I know there's customers out there who they go like, oh I've got like 10 terabytes or 20 terabytes or a hundred terabytes of data and that's a whole bunch.
I work with the other like broad end of customers, like you're at one end of the spectrum on that side and I'd argue like potentially like quite small like you know like we'd rather be working with like petabyte scale customers and I've seen customers that even like with AZ copy they're copying tens of petabytes a week, you know to Azure for a single workload just to get those up there.
Like there are workloads that are at that scale and they're doing online migrations and they're doing it quite successfully.
So yeah, don't view like Databox as an end all be all a lot of the time like once you look at it and you look at like the shipping times and the turnaround and the potential loss of fidelity along the way when it comes to things like metadata that you'd really might want to consider online migration along the way and there's a whole bunch of tools particularly for like Azure files that can potentially get you there or just for object storage in general.
- Alright. And even though the docs don't recommend AZ copy Scott, you can take Solace and the fact that chat GPT recommends using AZ copy , - There you go. Like I said, this is on my my 2024 list. I don't know like a lot of the files documentation was written kind of like before my time with AZ copy and a lot of the things that they call out like hey you're gonna lose some fidelity.
Like the only way that you lose fidelity is if the rest API doesn't support something which you know, the rest of API doesn't support any everything.
There have been gaps there and we've been kind of pushing the files team to make those things better and they have been like they recently introduced OAuth over rest, so on files rest you can actually do OAuth now, which is an interesting thing and opens up, opens up a whole bunch of broad scenarios to like our SDK customers and ultimately tools like easy copy or or anything like that along the way. So yeah, yeah, put it in the backlog.
We should come back maybe like mid-year and talk about online versus offline migrations. - Sounds like a plan. We will add it to the list. Scott is adding this to the list for once instead of me . But I think does that wrap us up for today? Anything else that likely - Does wrap us up for today? - Alright, well thank you Scott. This is an interesting discussion and we didn't even get into comparing this to SharePoint, which we do have other podcast episodes.
If you're curious and more of a SharePoint versus Azure files discussion, we can go hunt down one of those episodes. I don't know that some of the guidance, there's changed a whole lot, but we'll put that in the show notes if there's a topic you want us to dive deeper into. We have not done an outstanding job either, Scott, of we don't get a ton of listener questions, but we haven't always done a great job of addressing them timely.
We should also add that to our 2024 goals of if there is a topic someone wants more of a deep dive on to let us know and we will do a better job than maybe we have in the past of addressing those questions and pulling some of those in. So you can reach out via probably threads, Mastodon, iWatch, Twitter, Scott does not watch Twitter or just head over to our website, ms cloud it pro.com and look for the contact form and send us recommendations there.
Or if you're one of the members in Discord, you can always post stuff there as well. But with that Scott, we will wrap up on 2023 from a live perspective and welcome to 2024 to those of you listening to the recording. Perfect. Thanks Ben. Thanks God, If you enjoyed the podcast, go leave us a five star rating in iTunes. It helps to get the word out so more IT pros can learn about Office 365 and Azure.
If you have any questions you want us to address on the show or feedback about the show, feel free to reach out via our website, Twitter, or Facebook. Thanks again for listening and have a great day.