Gone are the days of storing local media files for use in things like scripts and wallpapers. With Intune, the only option you have to get a piece of media onto a device is packaging a custom Win32 app along side some scripting. While this can often be useful or in some cases the only solution, it’s not necessary for anything that’s safe for public eyes (a company logo file, a corporate wallpaper, etc).
Instead, you can use Azure Blob storage to host a public file that you can then call to with a URL. You can then use a multitude of transfer options to pull the file in PowerShell, or some Intune policies can actually go directly to the URL for content.
Note: I would not recommend using Blob to host massive files. If you need to transfer something huge like an app, you should still use a Win32 App Package.
What do you need?
- An Azure account
- A Resource Group to contain our storage account
- Azure Storage Explorer
- And a Container to host the media you wish to store
- If you plan to use this for wallpaper policy’s, make sure you have Windows Enterprise!
Azure Resource Group:
You can certainly use an existing resource group but if you don’t yet have one, there isn’t much of anything easier to make than a resource group.
- Head to the Azure Home.
- Choose Create a Resource.
- Search for “Resource Group” and locate the Microsoft offering.
- Simply give it a Name and Region and place it in an Azure Subscription.
Please note: The licensing of the contents will be affected / controlled by the subscription you place it in. - And don’t forget to hit Create.
Azure Storage Account:
- Head to the Azure Home
- Choose Create a Resource.
- Search for “Storage Account” and locate the Microsoft offering.
- Place it in your Resource Group.
- Give it a Name, put it in a Region, pick a Plan and Redundancy.
These obviously effect availability and thus cost. Since my share is just hosting some test files, I choose Standard and LRS. If you’re just storing your corporate wallpaper you probably don’t need ultra-available and word-ending level disaster proof storage. - For the remainder of the settings, I simply chose defaults but it’s best to consult with your Azure and Security teams.
- And don’t forget to actually hit Create.
Upload an Image to your Storage Account:
This is the part where you need the Azure Storage Explorer.*
- Fire up and authenticate to Azure with the Storage Explorer.
This is actually not super intuitive, you need to click the person logo on the left and hit “Sign in with Azure” and follow the prompts. It will not sign in automatically with your Windows credentials. - Once signed in, swap back to the file view and head into your Subscription.
- Then expand Storage accounts, find your Storage Account, right click Blob Containers, and make a new Container.
- Once your Container has been made, right click it and choose Set Container Public Access Level.
The wording in the Storage Explorer is not quite as friendly as Azure itself. What you want is public access to your Container and thus you need Public read access for containers and blobs. - Once the permissions have been set, you can click the new container and drag and drop a PNG or JPG file (or whatever you want). This file will become publicly accessible on the internet!
- Then, right click the file and Copy URL to get the access URL for the media.
- Past the URL into your browser, and you should see the media load and present itself.
The end results should look something like this… Your image will be in the container.
And the URL should load the image.
*How to avoid Storage Explorer:
- Open the Storage Account.
- Look for Containers on the left side.
- Hit the + Icon at the top to add a Container.
- Give it a name and set it to Container (public).
- You can then click on the new Container to upload media, adjust existing media, etc – just like you would through the app.
- The Image URL can be obtained by clicking into the Image and looking for the URL property near the top.
PowerShell Example:
If you’re going to use this in PowerShell code, make sure you do something that locally caches the image/file rather than calling to the image on the web each time as that would incur unneeded cost.
Note: I would not recommend using Blob for huge file transfers, that’s best done as a Win32 app.
This can be achieved with a simple bit of code such as the below. You can then reference the image at its locally stored location elsewhere in your code.
#Your Image URL including the image name
$ImageFile = "https://XXXXXX.blob.core.windows.net/picture-storage/Microsoft.jpg"
#Just the image name
$ImageName = "Microsoft.jpg"
#This will determine where the image is stored. Alter $Env:Temp to another location if you wish.
#Just make sure to put it someone whoever is running the script will have permission.
$ImagePath = Join-Path -Path $Env:Temp -ChildPath $ImageName
If (!(Test-Path $ImagePath)) { Invoke-WebRequest $ImageFile -outfile $ImagePath
Write-host "Image file not found - Getting Image File!
Location: $($Env:Temp)\$($ImageName)"
}else{
Write-host "Image file already present!
Location: $($Env:Temp)\$($ImageName)"
}
Intune Policy Example:
The other great use for this is wallpaper files. Again, this requires Windows Enterprise or Education.
While I am a big fan of the preview Settings Catalog, they still don’t seem to support URL based images and instead only use local or network images.
Head into Intune / MEM if you are not there already.
- On the left chose Devices.
- Find Configuration Profiles down under Policy on the left hand side.
- Choose Create Profile at the top.
- Select Windows 10 and later.
- Choose Templates for the profile type.
- Locate and select the Device Restrictions template.
- Choose Create
- Give the policy a name such as “Wallpaper and Lock Screen”
- Under Locked Screen Experience, paste your lock screen image URL into the Locked Screeen Picture URL (Desktop Only) setting.
- Under Personalization put your image URL into the Desktop Background Picture URL (Desktop only).
- Scope the policy accordingly and save it.
Once created, your policy should look something like this:
This may take some time but eventually the policy should start to reach your devices and apply the backgrounds. This can require a reboot to take effect fully.
A Word of Caution:
Should you ever want to update your background, know two things.
- Change the image name and alter your policy to that new image name. Otherwise, if you just swap out your image with an identical file name, the devices won’t realize it’s a new file.
- Like everything in Intune, it won’t be instant. Devices should start to receive the image within a few hours and then need to reboot to apply it. The old corporate days of swapping the file, instantly rebooting, and getting the new image are gone.
To test a new image, just exclude your device from the policy, make a new policy with the new URLs, and scope it to your test devices.
Conclusion:
Azure Blob Storage is a great way to host simple files for easy retrieval and centralized storage of common files. With this you should now be able to easily update and control elements of your corporate branding along with utilize your storage for PowerShell scripting.
Disclaimer:
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 