Welcome to Managing Azure Storage with AzCopy and Azure Storage Explorer. I'm Guy Hummel. To get the most from this course, you should already have some knowledge of Azure Storage. I'll show you two different ways of working with Azure Storage. If you prefer a graphical user interface, then you can use Azure Storage Explorer, which is an application that runs on Windows, MacOS, and Linux. If you're comfortable with the command line, then you can use AzCopy. Let's start with Azure Storage Explorer. First you need to download it from Microsoft. The URL for this page is in the transcript below. Select your operating system and click the 'Download' button. On a Mac, you just need to open the zip file and then run the Storage Explorer application. On Windows and Linux, you need to run an installation program. The first thing you'll need to do is sign into your Azure Storage account. Unless you're using a special Azure environment, leave this set to Azure and click 'Next'.

It opens a browser tab and asks you to authenticate. I'm already logged in, so once I select my account, I'm authenticated and I can close this tab and go back to Storage Explorer. Over here, you can choose your subscription and your storage account. I have an account called camonthlyreports and a blob container in it called monthly-reports. When I click on the container, it shows me the blobs in it. I don't have any blobs in this container which is why nothing shows up here. I'll upload some files into it so we have something to work with. You can either upload a whole folder or individual files. If I were to choose folder, then it would create a virtual folder inside the container, which isn't what I want in this case. So, I'm going to upload the files that are in the folder. I can select all of the files by holding down the 'Shift' key when I click the bottom one. That way they'll all get uploaded at the same time.

Now all of the files are in the container. If you right click on one of the files, you can see that there are lots of options for what we can do with it. For example, we could copy it, or delete it, or change its access tier, such as if we wanted to move it to the cool tier. I'll show you how to copy a blob to another container. First, let's create a second container so we have a place to copy the blob to. If we right-click on blob containers, there's an option to create a blob container. Let's call it Copies. Now, if we go back to the first container, we can right-click on a file and select 'Copy'. It's not obvious that we did anything, but if we go to the second container, we can click the 'Paste' button and it'll copy that blob into this container. You might have noticed something interesting down here. It says 'Copy AzCopy Command to Clipboard'. It turns out that Azure Storage Explorer uses the AzCopy command when it needs to copy blobs. And if you want to see the actual command, you can click here.

Now it's on the clipboard, so we have to paste it somewhere to see it. I'll paste it to a text editor. It kind of looks like gibberish, doesn't it? Well it's not as bad as it looks. The basic command is just 'azcopy copy' then the URL of the source and the URL of the destination. So, why do you have to put 'copy' after 'azcopy'? That's because the AzCopy command can also do other things besides just copying files, so the name of the utility is a bit misleading. For example, if you wanted to delete a blob, you'd start the command with azcopy remove. Okay, so why are the URLs so long? That's because the URL contains a shared access signature, or SAS. It's the part after the question mark. A SAS gives access to resources in a storage account for a limited amount of time. You can generate a SAS yourself if you want to give someone access to a particular resource for, let's say, the next week. But Storage Explorer generated a SAS for the source and a SAS for the destination for you.

You don't have to use them though, because there's another way to provide authentication. Azure Active Directory. If you have an Azure account that's authorized to access the source and destination, then you don't need to use shared access signatures. There's something very important you need to know to get this to work though. Even if you're the owner of the source and destination storage accounts, you could still get a permission error. You're probably thinking, what? How is that possible? Well, it turns out that your Azure Active Directory account needs to have the Storage Blob Data Contributor role for the source and destination storage accounts if you want to copy blobs using AzCopy. In this example, I'm using the same storage account for both the source and the destination, so I only need to give myself the Storage Blob Data Contributor role for that storage account.

To see whether you have that role assigned to you or not, go into the storage account, select 'Access Control', and then click 'View my access'. You can see that I have that role assigned to me, but if you don't then click on the role assignments tab and assign it to yourself. Or if you don't have permission to do that, then ask an administrator to do it for you. If that would be a problem, then you could use shared access signatures instead. Okay, now I'll show you how to run the AzCopy command. I could install AzCopy on my desktop, but since it's already installed in Cloud Shell, let's use that instead. But we still need to do one more thing first. Type 'azcopy login' to authenticate. Then go to this URL and copy and paste this code. Then choose your Azure account and click 'Continue'. All right, now we can finally try to copy a blob. First type azcopy copy, then put in the URL of the source blob.

This is the name of the storage account, this is the name of the container, and this is the name of the blob. Note that if we were including a shared access signature at the end of the URL, we'd need to put quotes around the whole thing, but since we're not using a SAS, we don't need to. Now put in the URL of the destination. If we wanted to give the blob copy a different name than the original one, we type a different name here. We could even leave the blob name out and just give the URL of the container where we want to copy the blob, but it doesn't hurt to give the name. In the AzCopy command we got from Azure Storage Explorer, there were some options at the end. The first one was overwrite=prompt. This means that if the command will overwrite a blob in the destination, then it should ask whether you actually want to overwrite it before doing so.

Since we're copying the same blob that we already copied using Storage Explorer, this option will matter for our example. If we don't include this option, then it'll overwrite the blob by default. Let's include this option so we can see what the prompt looks like. The next one is s2s-preserve-access-tier=false. This tells it not to ensure that the access tier of the destination blob is the same as the one for the source blob. By default, this option is true. For our example, there's no good reason to set this to false, so we can leave this option out entirely. The next one is include-directory-stub=false. This is kind of an obscure option and it's false by default anyway, so we can leave it out. The next one is recursive, which means that if you're copying a folder from your local file system, it will recursively copy its subfolders as well. That's not what we're doing, so we can leave this out too. The last one is log-level=INFO.

This refers to how much information is sent to the AzCopy log file and INFO is the default, so we don't need to include this one either. Okay, let's run it. There's the prompt we were expecting that's asking if we want to overwrite the blob. To say yes, type y. And it's done. If you want to see all of the options that are available, you can type azcopy copy -h. But it's easier to read if you go to this web page. Now after seeing that AzCopy is more difficult to use than Azure Storage Explorer, you might be wondering why you'd even use AzCopy. After all, Storage Explorer actually runs AzCopy under the hood, so you don't have to use it yourself. Well, if you need to automate your copying activities, then you can write scripts that contain AzCopy commands. It's also possible to do it by calling the Azure Storage Client Libraries in your code. They're available for a variety of languages such as .NET, Java, and Python.

But if you want to put something together quickly, it's much easier to use AzCopy. However, Azure Storage Explorer is better than AzCopy for general storage management because it supports more operations and storage types than AzCopy does. You can use it to manage not only blobs but also queues, tables, file shares also known as Azure Files, and Data Lake Storage Gen2. The Azure Storage Client Library support all of the storage types too, of course, but you have to write code to use them, so they're not meant for doing storage management manually. AzCopy supports blobs, file shares, and Data Lake Storage Gen2, but it doesn't support queues or tables, so it's not as robust as Storage Explorer. And that's it for AzCopy and Azure Storage Explorer. Please give this course a rating, and if you have any questions or comments, please let us know. Thanks.