As organizations increasingly integrate digital solutions, management and deployment of software becomes paramount. Within this framework, Microsoft’s Windows Store stands as a pivotal feature, offering a vast repository of apps and services. Understanding how enable the Microsoft Store for all users can be key, especially for large-scale IT operations.
Background
Microsoft’s Windows Store was introduced to simplify the application deployment process. However, there might be scenarios where the Windows Store is disabled either by default or through certain policies. For IT professionals and Managed Service Providers (MSPs), having the capability to enable it across multiple user profiles is not just a convenience – it’s a necessity. Enter the provided script, a powerful tool tailored to enable the Windows Store for all users, both existing and newly created.
The Script:
#Requires -Version 5.1 <# .SYNOPSIS Enables the Windows Store for all users and newly created users. .DESCRIPTION Enables the Windows Store for all users and newly created users. No parameters needed Enables the Windows Store for all users and newly created users. .EXAMPLE (No Parameters) Enables the Windows Store for all users and newly created users. .OUTPUTS None .NOTES Minimum OS Architecture Supported: Windows 10, Server 2016 Release Notes: Initial Release By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use. Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA). #> [CmdletBinding()] param () begin { function Test-IsElevated { $id = [System.Security.Principal.WindowsIdentity]::GetCurrent() $p = New-Object System.Security.Principal.WindowsPrincipal($id) $p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator) } function Test-IsSystem { $id = [System.Security.Principal.WindowsIdentity]::GetCurrent() return $id.Name -like "NT AUTHORITY*" -or $id.IsSystem } if (!(Test-IsElevated) -and !(Test-IsSystem)) { Write-Error -Message "Access Denied. Please run with Administrator privileges." exit 1 } # Setting up some functions to be used later. function Set-HKProperty { param ( $Path, $Name, $Value, [ValidateSet('DWord', 'QWord', 'String', 'ExpandedString', 'Binary', 'MultiString', 'Unknown')] $PropertyType = 'DWord' ) if (-not $(Test-Path -Path $Path)) { # Check if path does not exist and create the path New-Item -Path $Path -Force | Out-Null } if ((Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore)) { # Update property and print out what it was changed from and changed to $CurrentValue = (Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore).$Name try { Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false -ErrorAction Stop | Out-Null } catch { Write-Error "[Error] Unable to Set registry key for $Name please see below error!" Write-Error $_ exit 1 } Write-Host "$Path$Name changed from $CurrentValue to $($(Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore).$Name)" } else { # Create property with value try { New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false -ErrorAction Stop | Out-Null } catch { Write-Error "[Error] Unable to Set registry key for $Name please see below error!" Write-Error $_ exit 1 } Write-Host "Set $Path$Name to $($(Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore).$Name)" } } # This will get all the registry path's for all actual users (not system or network service account but actual users.) function Get-UserHives { param ( [Parameter()] [ValidateSet('AzureAD', 'DomainAndLocal', 'All')] [String]$Type = "All", [Parameter()] [String[]]$ExcludedUsers, [Parameter()] [switch]$IncludeDefault ) # User account SID's follow a particular patter depending on if they're azure AD or a Domain account or a local "workgroup" account. $Patterns = switch ($Type) { "AzureAD" { "S-1-12-1-(d+-?){4}$" } "DomainAndLocal" { "S-1-5-21-(d+-?){4}$" } "All" { "S-1-12-1-(d+-?){4}$" ; "S-1-5-21-(d+-?){4}$" } } # We'll need the NTuser.dat file to load each users registry hive. So we grab it if their account sid matches the above pattern. $UserProfiles = Foreach ($Pattern in $Patterns) { Get-ItemProperty "HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionProfileList*" | Where-Object { $_.PSChildName -match $Pattern } | Select-Object @{Name = "SID"; Expression = { $_.PSChildName } }, @{Name = "UserHive"; Expression = { "$($_.ProfileImagePath)NTuser.dat" } }, @{Name = "UserName"; Expression = { "$($_.ProfileImagePath | Split-Path -Leaf)" } } } # There are some situations where grabbing the .Default user's info is needed. switch ($IncludeDefault) { $True { $DefaultProfile = "" | Select-Object UserName, SID, UserHive $DefaultProfile.UserName = "Default" $DefaultProfile.SID = "DefaultProfile" $DefaultProfile.Userhive = "$env:SystemDriveUsersDefaultNTUSER.DAT" # It was easier to write-output twice than combine the two objects. $DefaultProfile | Where-Object { $ExcludedUsers -notcontains $_.UserName } | Write-Output } } $UserProfiles | Where-Object { $ExcludedUsers -notcontains $_.UserName } | Write-Output } } process { $Path = "SoftwarePoliciesMicrosoftWindowsStore" $Name = "RemoveWindowsStore" $Value = 0 # Get each user profile SID and Path to the profile. If there are any exclusions we'll have to take them into account. $UserProfiles = Get-UserHives -IncludeDefault # If the Disable-WindowsStore script was used we'll need to check applocker [xml]$AppLockerXML = Get-AppLockerPolicy -Local -Xml if ($AppLockerXML.AppLockerPolicy.RuleCollection.FilePublisherRule) { $AppLockerXML.AppLockerPolicy.RuleCollection.FilePublisherRule | ForEach-Object { if (($_.Action -eq "Deny") -and ($_.Conditions.FilePublisherCondition.ProductName -like "*Microsoft.WindowsStore*")) { Write-Warning "Removing AppLocker file publishing rules for the Windows Store!" [Void]$_.ParentNode.RemoveChild($_) } } if($AppLockerXML.AppLockerPolicy.RuleCollection.FilePublisherRule.id.Count -eq "1" -and $AppLockerXML.AppLockerPolicy.RuleCollection.FilePublisherRule.Name -eq "(Default Rule) All signed packaged apps"){ $AppLockerXML.AppLockerPolicy.RuleCollection.FilePublisherRule | ForEach-Object { if($_.ParentNode){ [Void]$_.ParentNode.RemoveChild($_) } } $AppLockerXML.AppLockerPolicy.RuleCollection | ForEach-Object { if($_.Type -eq "Appx"){ $_.EnforcementMode = "NotConfigured" } } } $AppLockerXML.Save("$env:TEMPapplocker.xml") Set-AppLockerPolicy -XmlPolicy "$env:TEMPapplocker.xml" Remove-Item "$env:TEMPapplocker.xml" } $script:DisabledWinRun = $true $failedUsers = @() # Loop through each profile on the machine Foreach ($UserProfile in $UserProfiles) { # Load User ntuser.dat if it's not already loaded If (($ProfileWasLoaded = Test-Path Registry::HKEY_USERS$($UserProfile.SID)) -eq $false) { Start-Process -FilePath "cmd.exe" -ArgumentList "/C reg.exe LOAD HKU$($UserProfile.SID) `"$($UserProfile.UserHive)`"" -Wait -WindowStyle Hidden } # Manipulate the registry $key = "Registry::HKEY_USERS$($UserProfile.SID)$($Path)" Set-HKProperty -Path $key -Name $Name -Value $Value -PropertyType DWord if ($(Get-ItemProperty -Path $key -Name $Name -ErrorAction Ignore).$Name -ne $Value) { $script:DisabledWinRun = $false $failedUsers += $UserProfile.UserName } # Unload NTuser.dat If ($ProfileWasLoaded -eq $false) { [gc]::Collect() Start-Sleep 1 Start-Process -FilePath "cmd.exe" -ArgumentList "/C reg.exe UNLOAD HKU$($UserProfile.SID)" -Wait -WindowStyle Hidden | Out-Null } } Start-Sleep -Seconds 30 if ($script:DisabledWinRun) { # All $UserProfiles updated exit 0 } else { $failedUsers | ForEach-Object { Write-Error "Failed to update user `"$_`"" } Write-Error "One or more user profiles failed to update" exit 1 } } end {}
Access 300+ scripts in the NinjaOne Dojo
Detailed Breakdown
The script operates in a clear sequence:
Initialization:
- Two functions, Test-IsElevated and Test-IsSystem, check for the script’s requisite privileges.
- The script then sets up another function, Set-HKProperty, to facilitate registry operations.
- A more complex function, Get-UserHives, retrieves registry paths for all actual users.
Process:
- Defines the path, name, and value to enable the Windows Store.
- Retrieves user profiles and checks for any app locker rules that might prevent access to the Windows Store, making amendments as necessary.
- Iterates through each user profile, manipulating the registry to ensure the Windows Store is enabled.
- Validates the success of the operation.
Termination:
- The script ends by providing status feedback.
Potential Use Cases
Case Study: Imagine a large educational institution migrating its software infrastructure. They’ve recently integrated with Microsoft’s ecosystem but find out that the Windows Store is inaccessible to students and faculty. Instead of individually configuring thousands of profiles, our script seamlessly addresses the issue at once, ensuring timely access to necessary applications for everyone.
Comparisons
While manual configurations or employing separate tools are options, they can be cumbersome and error-prone, especially on a larger scale. This script automates and streamlines the process, greatly reducing the chance of mistakes while saving time.
FAQs
- Is admin privilege necessary to run this script?
Yes, it requires elevated privileges. - Will this script work on older Windows versions?
It’s designed for Windows 10 and Server 2016 onwards. - Can specific users be excluded?
Yes, exclusions can be handled through the Get-UserHives function parameters.
Implications
While the script greatly simplifies enabling the Windows Store, unmonitored access might expose users to unvetted apps. IT professionals should ensure a balance between accessibility and security, considering potential vulnerabilities.
Recommendations
- Always backup current settings before deploying such scripts.
- Regularly review the enabled apps within the Windows Store to ensure they comply with organizational guidelines.
- Continuously educate users about safe app practices.
Final Thoughts
NinjaOne, with its holistic IT approach, complements tools like this script, offering streamlined management and more comprehensive oversight. By integrating both, IT professionals can not only “Enable Microsoft Store” seamlessly but also ensure its optimized, secure use.