-->
Adventures & experiences in contemporary technology
Recently, I managed to use 10AppsManager to remove most of the in-built apps from a Windows 10 virtual machine that I have for testing development versions in case anything ugly were to appear in a production update. Curiosity is my excuse for letting the tool do what it did and some could do with restoration. Out of the lot, Windows Store is the main one that I have sorted so far.
The first step of the process was to start up PowerShell in administrator mode. On my system, this is as simple as clicking on the relevant item in the menu popped up by right clicking on the Start Menu button and clicking on the Yes button in the dialogue box that appears afterwards. In your case, it might be a case of right clicking on the appropriate Start Menu programs entry, selecting the administrator option and going from there.
With this PowerShell session open, the first command to issue is the following:
Get-Appxpackage -Allusers > c:\temp\appxpackage.txt
This creates a listing of Windows app information and pops it into a text file in your choice of directory. Opening the text file in Notepad allows you to search it more easily and there is an entry for Windows Store:
Name : Microsoft.WindowsStore
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : X64
ResourceId :
Version : 11607.1001.32.0
PackageFullName : Microsoft.WindowsStore_11607.1001.32.0_x64__8wekyb3d8bbwe
InstallLocation : C:\Program Files\WindowsApps\Microsoft.WindowsStore_11607.1001.32.0_x64__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.WindowsStore_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-3224249330-198124288-2558179248-1001
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
Dependencies : {Microsoft.VCLibs.140.00_14.0.24123.0_x64__8wekyb3d8bbwe,
Microsoft.NET.Native.Framework.1.3_1.3.24201.0_x64__8wekyb3d8bbwe,
Microsoft.NET.Native.Runtime.1.3_1.3.23901.0_x64__8wekyb3d8bbwe,
Microsoft.WindowsStore_11607.1001.32.0_neutral_split.scale-100_8wekyb3d8bbwe}
Using the information from the InstallLocation field, the following command can be built and executed (here, it has gone over several lines so you need to get your version onto a single one):
Add-AppxPackage -register “C:\Program Files\WindowsApps\Microsoft.WindowsStore_11607.1001.32.0_x64__8wekyb3d8bbwe\AppxManifest.xml” -DisableDevelopmentMode
Once the above has completed, the app was installed and ready to use again. As the mood took me, I installed other apps from the Windows Store as I saw fit.
In Windows 10, the preferred place to look if you fancy prompting an update of the system is in the Update & Security section of the Settings application. At the top is the Windows Update and the process usually is as simple as pressing the Check for updates button. For most of the time, that has been my experience but it stopped working on my main Windows 10 virtual machine so I needed to resolve the problem.
Initially, going into the Advanced Options section and deselecting the tick box for Give me updates for other Microsoft products
when I update Windows helped but it seemed a non-ideal solution so I looked further. It was then that I found that manually resetting a system’s Windows Updates components helped others so I tried that and restarted the system.
The first part of the process was to right-click on the Start Menu button and select the Windows PowerShell (Admin) entry from the menu that appeared. This may be replaced by Command Prompt (Admin) on your system on your machine, but the next steps in the process are the same. In fact, you could include any commands you see below in a script file and execute that if you prefer. Here, I will run through each group in succession.
From either PowerShell or the Command Prompt, you need to stop the Windows Update, Cryptographic, BITS (or Background Intelligent Transfer Service) and MSI Installer services. To accomplish this, execute the following commands at a command prompt:
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
With the services stopped, it is then possible to rename the SoftwareDistribution
and Catroot2 folders so you can refresh everything to remove them. To accomplish this, execute the following pair of commands using either PowerShell or the Command Prompt:
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 Catroot2.old
Once you have the folders renamed, then you can start the Windows Update, Cryptographic, BITS and MSI Installer services by executing the following commands in either PowerShell or the Command Prompt:
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
Once these have completed, you may close the PowerShell or Command Prompt window that you were using and restart the machine. Going into the Update & Security section of the Settings tool afterwards and pressing the Check for updates button now builds new versions of the folders that you renamed and this takes a little while longer than the usual update process. Otherwise, you could let your system rebuild things in its own time. As it happens, I opted for manual intervention and all has worked well since then.
It seems that the Rename-Item commandlet in Powershell is a very useful tool when it comes to smarter renaming of files. Even text substitution is a possibility and what follows is an example that takes the output of the Dir command for listing the files in a directory and replaces hyphens with underscores in each one.
Dir | Rename-Item –NewName { $_.name –replace “-“,”_” }
The result is that something like the-file.txt becomes the_file.txt. This behaviour is reminiscent of the rename command found on Linux and UNIX systems, where regular expressions can be used like in the following example that has the same result as the above:
rename ‘s/-/_/g’ *
In both cases, you do need to be careful as to what files are in a directory for this though the wildcard syntax on Linux or UNIX will be more familiar who has worked with files via almost any command line. Another thing to watch in the UNIX world is that ** parses the whole directory structure and that could be something that is not wanted for much of the time.
All of this is a far cry from the capabilities of the ren or rename command used in the days of MS-DOS and what has become the legacy Windows command line. Apart from simple renaming, any attempt at tweaking a filename through substitution ended up with the extra string getting appended to filenames when I tried it. Thus, the Powershell option looks better in comparison.
Recently, a timestamp got changed on an otherwise unaltered file on me and I needed to change it back. Luckily, I found an answer on the web that used PowerShell to do what I needed and I am recording it here for future reference. The possible commands are below:
$(Get-Item temp.txt).creationtime=$(Get-Date "27/10/2014 04:20 pm")
$(Get-Item temp.txt).lastwritetime=$(Get-Date "27/10/2014 04:20 pm")
$(Get-Item temp.txt).lastaccesstime=$(Get-Date "27/10/2014 04:20 pm")
The first of these did not interest me since I wanted to leave the file creation date as it was. The last write and access times were another matter because these needed altering. The Get-Item commandlet brings up the file, so its properties can be set. Here, these include creationtime
, lastwritetime
and lastaccesstime
. The Get-Date commandlet reads in the provided date and time for use in the timestamp assignment. While PowerShell itself is case-insensitive, I have opted to show the camel case that is produced when you are tabbing through command options for the sake of clarity.
The Get-Item and Get-Date have aliases of gi
and gd
, respectively and the Get-Alias commandlet will show you a full list while Get-Command (gcm
) gives you a list of commandlets. Issuing the following gets you a formatted list that is sent to a text file:
gcm | Format-List > temp2.txt
There is some online help but it is not quite as helpful as it ought to be so I have popped over to Microsoft Learn whenever I needed extra enlightenment. Here is a command that pops the full thing into a text file:
Get-Help Format-List -full > temp3.txt
In fact, getting a book might be the best way to find your way around PowerShell because of all its commandlets and available objects.
For now, other commands that I have found useful include the following:
Get-Service | Format-List
New-Item -Name test.txt -ItemType "file"
The first of these gets you a list of services while the second creates a new blank text file for you and it can create new folders for you too. Other useful commandlets are below:
Get-Location (gl)
Set-Location (sl)
Copy-Item
Remove-Item
Move-Item
Rename-Item
The first of the above is like the cwd
or pwd
commands that you may have seen elsewhere in that the current directory location is given. Then, the second will change your directory location for you. After that, there are commandlets for copying, deleting, moving and renaming files. These also have aliases so users of the legacy Windows command line or a UNIX or Linux shell can use something that is familiar to them.
Little fixes like the one with which I started this piece are all very good to know but it is in scripting that PowerShell really is said to show its uses. Having seen the usefulness of such things in the world on Linux and UNIX, I cannot disagree with that and PowerShell has its own IDE too. That may be just as well given how much there is to learn. That especially is the case when you might need to issue the following command in a PowerShell session opened using the Run as Administrator option just to get the execution as you need it:
Set-ExecutionPolicy RemoteSigned
Issuing Get-ExecutionPolicy
will show you if this is needed when the response is: Restricted. A response of RemoteSigned
shows you that all is in order, though you need to check that any script you then run has no nasty payload in there, which is why execution is restrictive in the first place. This sort of thing is yet another lesson to be learnt with PowerShell.
Linux and UNIX have the touch command for changing the creation dates and times for files. However, it also will create empty text files for you as well. In fact, there are times when I feel the need to do this sort of thing on Windows too and the following command accomplishes the deed when run in a Command Prompt window:
type nul > command.bat
Essentially, null output is sent to a file that is created anew, command.bat in this case. Then, you can edit it in Notepad (or whatever is your choice of text editor) and add in what you need. This will not work in Powershell so you need another command for that:
New-Item command.bat -type file
This uses the New-Item command, which also can be used to create folders as well if you so desire. Then, the command becomes the following:
New-Item c:\commands -type directory
Note that file on the previous example has become directory and there is the -force option should you need to overwrite what already exists for some reason…
That other use of the UNIX/Linux touch command can be performed from the Command Prompt too and here is an example command:
copy /b file.txt +,,
The /b switch switches on binary behaviour for the copy command though that appears to be the default action anyway. The + operator triggers concatenation and ,, gets around not having a defined destination because you cannot copy a file over itself. If that were possible, then there would no need for special syntax for changing the date and time for a file.
For doing the same thing with Powershell, try the following:
(GetChildItem test.txt).LastWriteTime=Get-Date
The GetChildItem command has aliases of gci, dir and ls and the last two of these give away its essential purpose. Here, it is used to pick out the test.txt file so that its timestamp can be replaced with the current date and time returned by the Get-Date command. The syntax looks a little more complex even if it achieves the same end. Somehow, that touch command is easier to explain. Are Linux and UNIX that complicated after all?
It’s amazing what ideas Linux gives that you wouldn’t encounter that clearly in the world of Windows. One of these is output and command line history so a script can be created. In the Windows world, this would be called a batch file. Linux usefully has the history command and it does the needful for taking a snapshot like so:
history > ~/commands.sh
All of the commands stored in a terminal’s command history get stored in the commands.sh in the user’s home area. The command for doing the same thing from the Windows command line is not as obvious because it uses the doskey command that is intended for command line macro writing and execution. Usefully, it has a history option that tells it to output all the commands issued in a command line session. Unless, you create a file with them in there, there seems to be no way to store all those commands across sessions, unlike UNIX and Linux. Therefore, a command like the following is a partial solution that is more permanent than using the F7 key on your keyboard:
doskey /history > c:\commands.bat
Windows Powershell has something similar too and it even has aliases of history and even h. All Powershell scripts have file extensions of ps1 and the example below follows that scheme:
get-history > c:\commands.ps1
However, I believe that even Powershell doesn’t carry over command history between sessions though Microsoft are working on adding this useful functionality. They could co-opt Cygwin of course but that doesn’t seem to be their way of going about things.