I have absolutely not a faintest clue about what you mean? "Audit Mode will not function under PowerShell"? Audit Mode is not meant to function under anything, it's the special Windows customization mode you boot to from OOBE region selection screen with CRTL + SHIFT + F3. PowerShell has nothing to do with Audit Mode, and vice versa Audit Mode has nothing to do with PowerShell.
When I selected Cmd.exe, windows put me into Windows PowerShell(admin). When I tried to execute the command
%windir%\system32\sysprep\sysprep.exe /oobe /reboot /unattend:d:\relocate.xml it failed telling me that Sysprep.exe is not a valid command. I had to find a way to get into the real cmd.exe and then run the above command, and then it worked.
Tom
If I understood you right, Those line of commands won't work in power shell. Make sure you opened the Admin power shell. Type cmd hit enter, than type your commands.
Windows now sets power shell by default. Thus go to your task bar settings. Switch off the option that defaults in to power shell.
Next time you enter windows key +x+a cmd admin will open.
Kari,
I can't move the users folder no matter what I had tried. I read some of the posts here, where the consensus for the culprit appears to be the manufacturers' customizations on the pre installed Windows.
I spoke to Lenovo about this and finally someone who sounded like, recognized the circumstances told me that, they do offer an un altered version of the windows that can be customized. However, I have to purchase it from them. I removed most obvious files/folders from the system. However, sysprep still fails after the reboot. As most people posted here.
My question is the following ;
After running the syprep, system runs into continuous bootloop however, after restoring it from the image file, system activated Administrator user folder relocates to the D drive. Nonetheless, none of the new user(s) or reactivated user(s) folders relocates at all.
I don't want to work with local Administrator mainly because of the security concerns as well the need to constantly tweak the system IDEs to work with the local Administrator.
Is there a way to fish through system to remove OEM customizations?
OK, now I got you. I had no idea that opening Command Prompt would be a problem for some users, I've now edited tutorial to offer tutorial link for those who need help in getting Command Prompt opened. Extract from tutorial:
Anyway, PowerShell not only gives an error message (#1 in screenshot below) when a Win32 command can't be run, it also shows this suggestion (#2):
Suggestion [3 ,GeneraI]: The command sysprep was not found, but does exist in the current location. Windows PowerShell doees not load commands from the current location by default. If you trust this command, instead type ".\Sysprep"
Doing as suggested (#3), adding .\ in front of command, it works perfectly:
Notice that you can also start Command Prompt within PowerShell with command cmd:
This switches PowerShell to Command Prompt.
Kari
To run Sysprep on an existing pre-installed OEM Windows installation is always a bit risky. That's why I have added this warning at the beginning of Method Two:
Warning
Do not proceed before creating a system image!
Sysprepping an existing installation with an OEM pre-installed Windows is risky. Manufacturers might have their own unattended answer files in place which ignore your custom unattended files. Anything can go wrong when sysprepping an existing installation, I do not recommend doing this.
If you decide to try it and it fails and you post about it, I will remind you about this warning asking you to restore the system image you made before proceeding.
Additionally, in Windows 10, this method might cause existing user accounts losing Start Menu and Search functionality. All new accounts will be OK.
Short: relocating Users folder with Sysprep should only be done on new, clean installs. Trying this Method Two, relocating Users on an existing installation might force you to do a complete reinstall or restore your PC to factory state.
Some users have managed it by searching the PC for every possible unattend.xml and setup.xml file and removing them but my sincere recommendation is to only use Method Two, relocating Users on existing installation if that existing installation is a clean install made by yourself, not a pre-installed OEM Windows.
Kari
Hello sir,
Just followed method 1 on new pc with ssd & hdd. Came out fine. So grateful for your step-through... Checking Drive ID letters in Disk management first, local user trick for full username, etc. Invaluable... to have the PC the way it should be from start.
Heart sunk as I got to the %windir%\system32\sysprep\sysprep.exe /oobe /reboot /unattend:d:\relocate.xml command.
I couldn't get the command to work... checked and checked to find what was wrong.
Turned out I'd written /unattended:d:\ stedda /unattend:d:\.
Now things are great here in User Folder heaven Kari. Thanks so much.
Best
Kari,
I know the risks and have had my continually updated Macruim image files on hand. My question is the following;
Only the Local System Administrator was moved. And I can't add a new user to this location. Do you have any ideas as to why one account can be transferred but not the rest, Albeit only the Administrator?
These were the steps I took to semi-Accomplish such move;
1- Followed through your Method 1 instructions. Method 2 didn't work for me.
2- After running the Sysprep first time, windows goes into a continuous loop. However, after installing the Image files (Macrium - all partitions), Only the System activated Local Administrator is moved to D drive. I have done this at least eight times with various tweakings. It only worked on a clean Windows install. Meaning that the Windows 10 1703, re- installed from the image all the way through including the creation of the Default user profile. Then, the System local admin activated, audit mode activated, Sysprep reboot and entered into boot loop fail and finally re-installed windows again from the image all the way through and activated system admin. Basically, total of two complete installation cycles. The process didn't work with a dummy local Windows accounts or Microsoft admin account. Or Enabling and Disabling the accounts. I have tried the every-whichever version of the tweaks I could think of. The fact that the APPs folder is automatically relocated to D drive was very important to me. That's where the bulk of my stuff reside. Such as Gradle, NodeJs, Git, repositories, a bunch of SDKs, JDKs, Chocolatey, Android SDKs, IntelliJ, etc.
3- Nonetheless, in this process, not all of the System-Activated Administrator user files were relocated. For example, I had to use the Windows file-properties, move location functionality to move the other folders such as documents, downloads, pictures, etc. manually.
4- Although Windows properties location functionality did not work for relocating C drive Administrator 'Local' folder to D drive as a whole, this functionality did work for the relocating the 'LocalLow' and the 'Roaming' folders as a whole.As for the 'Local' folder, I had to use the Windows properties location functionality again to relocate its 'Local' sub-folders to D drive. Needless to say, that doesn't work for the Core-Windows folders. Hence they still reside in the C drive Administrator 'Local' folder.I know that having some Users folders relocated to D drive while having others still residing in the C drive can be risky and perhaps not recommended from my perspective. However, I use Macruim "Forever Incremental Backup for Folders", which makes me at ease in terms of my usage. I also use cloud backups.
An important factor to remember about utilizing the Windows properties location functionality is that You have to create the same folders with the exact syntax and name at the new Location. Thus if you are relocating 'LocalLow,' you will need to create a folder named 'LocalLow' at the desired location prior to relocating that folder.
Kari, I had two purposes writing the above details. First one was to give an idea for others who could not move their folders like I. Second one is to see if you, could make some sense out of it all, (why Just the Admin moves, not as a whole and why not others move) and perhaps could come up with some different ideas or recommendations
Today's internal SSD drives are extremely expensive as you would know, particularly 1 TB and up. Thus using external drives are an important factor for some of us. Hope we can find a better and healthier solution.
Attachment 134660
Attachment 134661
Attachment 134662
I read your post yesterday several times, not understanding anything. I decided to sleep on it, opened it this morning again and tried to understand. Did not understand.
I decided to print your post on paper, made a pot of coffee and concentrated on the printout, reading it certainly 15 to 20 times through trying to figure out what you were saying. No amount of coffee and time helped me to understand you, I am still totally unable to understand your post. It is simply totally uncomprehensive, not understandable, the process as you describe it impossible to understand.
Some facts:
- When you use Sysprep to relocate Users folder, you should absolutely not use any junctions or links thereafter
- When you use Sysprep to relocate Users folder, you should not manually create any system folders thereafter (like Documents, Pictures, Vides and so on)
- When you use Sysprep to relocate Users folder, you should not manually change any storage locations in folder properties or Settings app thereafter
- When Users folder will be relocated on a clean install with Sysprep, all future user profiles will be stored in new location. If one local admin account will be relocated and other users not, you have done something seriously wrong
In your case I simply recommend that you completely forget this method. You are clearly not understanding the tutorial, the Sysprep process and how the relocating will be done. I honestly think it's better that you do not try this anymore.
Kari
I'm quite familiar with your semantics that you have suggested at above. I am sorry for not being able to clarify it for you. I am one of those who cannot move the User folders by Utilizing your Method One and Two. I know how to USE CMD and its syntax requirements quite well. This is my last attempt and I won't try this again!
SUMMARY:
1) Method I or Method II did not work for me. Due to Lenovo hard coded + pre-installed customizations.
2) I did not make any ERRORs using your methods, I Debugged it several times!
3) I was able to move Only local system activated Administrator folder - AND not as a WHOLE.
4) Since some of the folks here could not make this work due to same or similar problems, I wanted to explain the steps I have taken to make it work. Perhaps, someone could benefit from it.
5) Since my steps did not relocate for All Users\ADMINISTRATOR files/folders, I had to use the Location properties to manually move most of the folders under LOCAL. Some system folders did not move under the LOCATION folder, However, Manual relocation process worked for All of the LocalLow and Roaming Folders
6) I wanted to get your opinion about these steps. Perhaps some Pros/Cons, or perhaps you may come up with some suggestions, as my steps are more of a patch work rather then a solid integrated solution! such as your Methods.
Below are these steps:
1- Install Windows 10 from Macrium Image.
2- Delete all non-System created user profiles and activate the System Local Admin.
3- Run sysprep.exe with XML file.
4- Let Windows go through a boot-loop crash.
5- Re-Install Image from Macrium.
6- Now User Folder with System Local Administrator is created.
7- However, Only an empty APPDATA folder and Net User data description file (NTUSER.DAT) reside Inside the Users\Administrator folder,
8- Manually relocate folders from C:\Users\Administrator\Pictures, Downloads, Contacts,...etc also \Local, LocalLow, Roaming to D:\Users\Administrator\...
9- Prior to relocating these folders from C:\Users\Administrator\*.* , you will need to manually create empty Folders with the same names in D:\Users\Administrator\....
10- Change ENVIRONMENT variables in CMD for the Local ADMINISTRATOR user profile if needed or as needed. Or run systemPropertiesAdvanced.exe from CMD.
11- Do not move the Windows System sub-folders UNLESS if you can move the ENTIRE Main folder as a whole.
EXAMPLE: Do NOT move the C:\Users\Administrator\Roaming\Microsoft\Windows\Start Menu folder itself. You need to move to ENTIRE MICROSOFT folder as a whole.
HOWEVER, it is better to not mess with these folders. I did not move System Windows and Microsoft folders.
12 - You will need to update Group Policy Settings for the System Administrator. Download and Run Administrative Template (.admx) from Microsoft Windows. This makes it more convenient while modifying the file/folder security settings when needed. For example, in my trials, APPDATA folder Application files/folders did not include the System Administrator Access under the security Settings. You need SYSTEM Administrator access to run the Applications such as Chocolatey, Power Shell scripts, etc. Instead of going into ADVANCED settings under SECURITY and ADDing System Administrator access for each of the folder/file one by one, this will enable the access to all files/folders by default.
13- All of the .EXE files for the downloaded Applications need to be set to Run As Administrator from its properties.
{I did not describe 10-11-12 in my initial posting, as I should have}
All System Applications such as Norton,MalwareBytes, etc. or IntelliJ must be installed to C:\ drive, not to D:\ drive. However, GRADLE, NODES, Chocolatey, Nuget,..etc. types can be downloaded to D:\Users\Administrator\APPDATA\Local
This method is not very convenient as it requires manipulation, however, it works 100% for me.
MY Main Purpose for Relocating these folders/files is the following ;
I am an Android Application Developer. AND ALL of my Repositories, GRADLE, SDKs, JDKs, NodeJS., GIT, BASH..etc reside under the APPDATA folder. This folder SIZE has exceeded 400 GB. AND the reason I mentioned the above is that; for someone who does not use the APPDATA folder the way I do, these steps might not be worth taking. AND if someone who has the same or similar needs for the capacity for utilizing the APPDATA folder as I do and knows what they are doing, It works 100%. Lastly, this a Risky Method and don't attempt to try it Unless you have Macrium or similar Software. DO not rely on Windows System RESTORE!!!
That's All
Last edited by redkidbytes; 13 May 2017 at 12:41.
Quote
