Can you post a screenshot how you defined the MIDI remote path in the script, please? More often than not, it’s just a typo or an additional blank that doesn’t belong there… I’ve been there, too 
1 Like
Hi Reco29, thanks for responding that fast.
For now I reverted back to the original script.
Here’s the screenshot:
Since my Default User folders are on F:\ I’d expect the script to use them.
But then I’m no coder …. 
I’d like them backups to go to the highlighted folder on the left …
Well, I finally made it work by pointing to the folders via a direct path:
So thanks again to the both of you @ASM & @Reco29 .
Have a great weekend/schönes Wochenende 
Ralf
Hi Ralf, what does your USERPROFILE environment variable look like?
Access to the data to be backed up and the default backup folder are derived from this variable:
$USERROOT = $Env:USERPROFILE # Current user's root path
$ADAT = “$($USERROOT)\AppData\Roaming” # Path to user-specific application data - Roaming
$ADATLOC = “$($USERROOT)\AppData\Local” # Path to user-specific application data - Local
$DOCS = “$($USERROOT)\Documents” # Path to user documents
$DEFAULT_BACKUP_FOLDER = “$($DOCS)\$($BRAND)\$($APP)\Backups” # Default backup folder
and further
$BackupFolder = $DEFAULT_BACKUP_FOLDER
$BakSubFolder = Join-Path $BackupFolder “$($APP)_$($Version)”
$FolderStub = “$($HOSTNAME)_$($TIMESTAMP2)”
$ArchiveFolder = Join-Path $BakSubFolder $FolderStub
In your screenshot, the Archive Folder is displayed as
C:\Users\Funky-Wolf\Documents\Steinberg... etc.
So, if your user folder is actually F:\Users\Funky-Wolf, this has to be reflected in the USERPROFILE environment variable so that the script uses this path instead of C:\Users\Funky-Wolf. This also eliminates the need to transfer by parameter or edit the backup folder in the script.
However, if your user folder is located on C: and only the Documents folder is on F:, you’ll have to specify this when calling the script with the parameter, e.g.
-BackupFolder “F:\Documents\Steinberg\Backups”
Alternatively, you can also write the path directly into the script, as you have done.
1 Like
This is the case indeed. So I’m glad I’d figured this out.
However, what happens on a restore? Specially concerning the MIDI Remote files (which I still keep losing each time I use C14)? Will they be restored to where they were collected or would I have to move them manually back to my “Documents” folder?
Thank you for chiming btw
I haven’t been even attempting to use this script, but had been following this topic, and this specific issue caught my eye due to an issue I’m having with a specific plugin developers’ presets due to a similar issue. Those presets expect plugins to be recalled to be in C:\Users\rickp\Documents\. However, on my system, I moved my Documents folder, using the official Windows 11 methods to D:\Documents, so the path actually should be D:\Documents\.
I just took a quick look at the script in question (I hadn’t even downloaded it previously), and it looked to me like it should be doing the right thing for setting up the default backup directory. (I didn’t try running it.)
However, here’s the likely rub:
If I go into CMD and echo %USERPROFILE%, it shows C:\Users\rickp as the result. However, if I type %USERPROFILE%\Documents into File Explorer, it takes me to D:\Documents.
Just poking around a bit in File Explorer with the Details field enabled, I can see that, if I just go to %USERPROFILE%\Documents (which clicking in the title bar shows as D:\Documents), then go up one level, it just displays the folder as Rick Paul. The Documents folder within that is selected (since I went up the level from there, and it shows the file location in the details field as being D:\. (This is also true if I check Downloads, Pictures, Music, and Videos in that same folder since I moved all to a different disk.) If I then go up another level, it is automatically selected to the Rick Paul folder, which details shows as a System folder in C:\Users.
This suggests to me there is something a little trickier in handling changed Documents (and Download, Pictures, etc.) file locations than just making a path off the %USERPROFILE% variable.
I’m not very knowledgeable in actual programming/scripting of this sort to have any suggestions on what specifically is needed to make this work correctly. And, FWIW, if I echo %USERPROFILE%\Documents in CMD, it shows C:\Users\rickp\Documents. Thus, there must be something special regarding the Documents item in that user profile folder that needs to be interpreted for this sort of case. I’d tried experimenting a bit with shortcuts in trying to work around the issue with the plugin presets I alluded to, and I had no luck with things I was thinking should probably work. (The plugin developer indicated it would be a VERY complex problem to fix, probably at least partly because all of their plugins have the same issue.)
Don’t worry, all data will be restored exactly where it was backed up. If necessary, folders will be created, existing files will be overwritten, and newly created files will be retained.
ADDITION:
The method suggested in the post below would also be more suitable in your case. Simply specifying the Backup folder doesn’t take into account the subfolders of the Documents folder (e.g. MIDI Remote). In your case, it would therefore be more advantageous to change
$DOCS = “$($USERROOT)\Documents” to
$DOCS = “F:\Documents”.
Alternatively, you can create a symbolic link to the actual location of the folder:
mklink /j “%USERPROFILE%\Documents” “F:\Documents”.
ADDITION 2:
There’s another alternative suggested by @mlib here. It can query the actual location of the system folders. This saves you from having to change the queries in the script if you have moved system folders to locations that differ from the Windows default.
2 Likes
The scripts exclusively use the value of the environment variable USERPROFILE, as output by the command set USERPROFILE. This user profile usually also contains the Documents folder and any subfolders. If only this folder (as in the @funkster1 post) is moved from the user folder (and not the user folder entirely), the corresponding entry
$DOCS = “$($USERROOT)\Documents”
has to be adjusted in the script, e.g. to
$DOCS = “D:\Documents”.
The other option is to create a symbolic link in the user folder that points to the actual location of the document folder:
mklink /j “%USERPROFILE%\Documents” “D:\Documents”.
1 Like
“Usually”, or perhaps “by default” (which tends to result in “usually”), being key. There is a stock Windows procedure to relocate these user folders, for example to another drive, which I wanted to do to get these folders off my NVME M.2 system drive an onto a spare SATA SSD moved over from my old system. (I especially don’t like Downloads being on my system drive, but also lots of applications store stuff other than stuff I’m actively putting there in Documents. Cubase’s use isn’t a big issue, but stuff like the caches for ARA plugins is a bigger one.)
The procedure I’d used (likely found from a Google AI search result when setting up my new system) was:
Step-by-Step Instructions:
Open File Explorer and navigate to your current Documents folder (usually under C:\Users\[Username]).
Right-click on the Documents folder and select Properties.
Go to the Location tab and click the Move... button.
Navigate to the new drive (e.g., D: drive), create a new folder (e.g., "Documents"), and select it.
Click Apply or OK. Windows will ask if you want to move all files from the old location to the new one; select Yes.
My expectation was that this would make any applications that used general Windows routines to find the Documents folder would work, and it does for most I’ve experienced, including Cubase, File Explorer, etc. The plugins I was alluding to had been the only exception I’d found previously.
Just now doing another Google search, specifically looking for an environment variable to specifically locate the user Documents folder, after saying there wasn’t one and various considerations, Google’s AI adds:
Note: If you have moved your Documents folder to a non-default location (e.g., OneDrive or a secondary drive), %USERPROFILE%\Documents may not work, and you will need to check the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders.
Looking in that area of the registry, beyond one of those keys with the long hex names (“{F42EE2D3-909F-4907-8871-4C22FC0BF756}” in this case, the only key I see that contains “D:\Documents” as the value is called “Personal”. On the other hand I do find “My Music” and “My Video” keys that point to their locations, with the Downloads location only being in a couple other of those keys with the long hex string names. So it’s not clear to me if there is an easy way to find a given user’s Documents directory in this case of having moved it elsewhere without tricks like changing information in a script or creating symbolic links.
I did try this, and I verified that it works around the plugin presets problem I’d alluded to. (The response given in CMD was “Junction created for C:\Users\rickp\Documents <<===>> D:\Documents”.) I’d attempted to do something similar using shortcuts previously, but that did not work. I’d totally forgotten about Windows having symbolic links (I was mainly used to using those in UNIX in the past).
FWIW, though, here is a picture of what comes up in File Explorer when I enter %USERPROFILE% as the path and focus on the Documents entry that was there prior to creating the symbolic link:
The icon I’ve pointed to with the (badly drawn arrow and text) was added by the symbolic link. Everything else there was there previously. It is the colorful icons for Documents, Downloads, Music, Pictures, and Videos that get to their new locations. The plain yellow Downloads folder is probably there because I did the moving the Downloads directory after having already done some installations that used the location that was on my C: drive. It is just an empty folder at this point, with the moved location being used by any apps that do downloads.
Would using [Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments)
be a viable option to
$DOCS = “$($USERROOT)\Documents”?
2 Likes
Yes, that’s a good alternative, especially if system folders have been moved. You can also extend this method to the other queries in the script, like this:
$HOSTNAME = [Environment]::MachineName # Computer name
$USERROOT = [Environment]::GetFolderPath(“UserProfile”) # Current user’s root path
$ADAT = [Environment]::GetFolderPath(“ApplicationData”) # Path to user-specific application data - Roaming
$ADATLOC = [Environment]::GetFolderPath(“LocalApplicationData”) # Path to user-specific application data - Local
$DOCS = [Environment]::GetFolderPath(“MyDocuments”) # Path to user documents
Sometimes a system folder remains if programs have blocked files during the move process or immediately recreate a folder in the old default path. However, this is then an ordinary folder and no longer a system folder. It can (and should) be deleted, after any data is moved to the new location.
The point I was trying to make, though, with the screenshot and my description of it was that there was no separate documents folder prior to my creating the symbolic link, only the current Documents folder that went to the D:\Documents drive when double clicked (and shows its file location as D:\). So there was no old Documents folder leftover to delete. Creating the symbolic link did add another icon.
This behavior seems analogous to what happened with Music, Pictures, and Videos with the similar move. Downloads was the only exception.
And the bottom line, on my system anyway, was that, with the exception of the one plugin developer’s plugins, all other relevant applications and plugins seemed to respect the relocated Documents directory. That suggests to me there must be some stock way of locating this directory programmatically, as opposed to just assuming it is a directory that adds “Documents” to the path given by “%USERPROFILE%”. What it is, however, I have no clue.
After moving the folder correctly, the user folder on C: should be “clean”. This means that the Documents, Music, Pictures and Videos folders should no longer appear in the user folder. In practice, however, programs may recreate the folders without asking.
This method exists and is described here.
1 Like
With the exception of the extra Downloads folder, that was indeed what happened in my case – the special folders (more colorful icons) are the only thing left, and they point to the right locations, as opposed to being literal subfolders of the user folder. As for the Downloads folder, I’m not positive why the difference, though it probably had something to do with my use of that folder in installing software ahead of making the location changes.
Ah, I missed that post as I just clicked the link in my email to your reply, not having time earlier to do any general forum reading. Thanks. (Not that I do any meaningful scripting myself these days, but it is good to know in case the need every comes up.)
Backup & Restore Scripts for Cubase on Windows 2026-02-23.zip (235.4 KB)
ZIP Content:
Backup Cubase.ps1 v1.06
Restore Cubase.ps1 v1.02
Backup & Restore Cubase - Quick Guide.pdf
Changes:
- Improved method for querying environment variables (thx to @mlib)
7 Likes
Hey…maybe something can continue having fun with this, but I took your script and heavily modified it into a WPF GUI version. It’s not fully working, since I kind of gave up on it. Maybe someone can mess around and get it to work.
I would say it’s like 80% there.
Could probably be used for other things, but it’s core is based on Cubase and ASM’s script.
Cubase Backup_WPF GUI_1.zip (7.1 KB)
Thank you for all this work and sharing with others, @ASM 
!
I don’t know enough computer stuff to do scripting.
If I simply open a W10 powershell, and type all the lines in … what exactly does happen?
1 Like
If you simply type a line of code into the PS console, it will be executed immediately. If you want to write a script, you’ll have to first create it as a *.ps1 file in a text editor (e.g. Notepad++) and then run it (for instructions on how you can run it, see the documentation for the Cubase backup/restore script).
1 Like