So basically I customized a Windows 10 install. I have the PerfLogs, Program Data, Temp and Users folders in C:\ replaced as symlinks to their actual location to D:\
The purpose being, I will only keep a image backup of C:\ and when the need arises that I need a fresh install of the OS, I will only overwrite the whole C: drive with the backup and don't even have to touch my old user profiles. It works without a glitch even as I moved my C: to an SSD.
I did it with a few simple tricks (I don't exactly remember everything I did, but once I got the build right, I just left it as it is as I thought I would never have to touch it again):
I remembered following tips and other guides like this:
https://commaster.net/content/windows-installation-tips-moving-user-folder-another-drive
the difference being I used symlinks instead of junctions with mklink command.
Some modification with registry and other files.
Several stages of booting until everything has been transferred and having windows re-create the profiles and configurations.
Anyways, I had to fix my Mom's PC, which was in a state of disarray as she thought she had to save all her files in C:\ and NEVER in Documents. I opted to install my customized Windows install, so if I need to fix it again, it would just be a cinch.
Before building this custom Windows install, I've made backups of my system with my usual backup tool, Paragon Partition Manager. They worked fine and when I had to change PC builds, such as changing my motherboard, all I had to do was change the drivers. So I thought with my custom Windows 10 install, that's all I had to do for my Mom's PC.
But I kept running into problems with Window's User Profile Service.
At first, it was having difficulty loading the Administrator account and seems to be defaulting to C:\Windows\System32\config\systemprofile, as it cannot seem to write to it's D:\Users\Administrator folder. I quickly fixed that, but, still, it can't load the Start Menu and other services.
The only one that was working almost completely was the user (just one - me) that was existing when I created the backup AND only works with a copy of the corresponding folder in D:\Users\MyUsername.
Obviously I wanted to create a user just for my Mom and one that is completely working and I don't wanna leave a copy of D:\Users\MyUsername in her PC. I figured all I had to do was create a user profile in Control Panel and Windows will recreate everything and all the configurations. The add user service in Control Panel wasn't working with Administrator, but only with MyUsername. But whenever I try to sign in to the newly created user, the "User Profile Service failed to sign-in" keeps popping up. I can sign into it in safe mode, at the first seemingly recreating everything with the first-time-sign-in-welcome-screen, but a lot of the services are not working. So creating another user profile with this new profile doesn't work.
More notably, I've tried:
net user username /add
and adding through advanced user profiles:
control userpasswords2
But the new registry keys for the new users in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList never gets created -- even after I go safe mode and manage to sign in to the new users.
I've also considered it might be a user permission issue, somehow being carried over from my PC build (if that makes sense, it still doesn't to me). Anyways, so with the newly created user logged in with safe mode, I tried changing permission for C: and D: for every single group to "Full Control". Then from that newly created user, create another user either through net user username /add or control userpasswords2. I even tried booting to Linux LiveCD and chmod-ding everything to 777 (I'm not even sure how that transfer to an NTFS. Then I try to sign in and even if I can forcibly sign in, it just isn't a glitch-free user profile.
Related
We are building system controlled by computer running windows 10 ltsc 2021. It is kind of a kiosk system. There is an account, lets call it user1 with local admin rights that will autologon with no password. It also requires quite a few user account customizations.
In the previous version of windows 10 ltsc, i used a baseline windows installation, created the account to be used in kiosk mode and performed all customizations. I used sysprep with unattended file that had CopyProfile set to TRUE, then boot WinPE and use dism to capture image for distribution to new systems.
It worked well until the file associations were reset after imaging, I could work around this issue by deleting certain registry elements before running sysprep (it could be also done offline on captured image).
Then we started building systems based on win 10 ltsc 2021. Immediately started to have different issue. After applying image, all items in Windows security area were not clickable. I could not click for example on Virus and threat protection to setup some virus scans. Recreating user account would fix that (have to create secondary account, delete user1 and create new user1). However the recreated user account would not have all customizations we need.
I started experimenting with CopyProfile set to false. I go to audit mode right before creating user in original windows installation. I install updates, some extra apps we need and also make some non user account specific customizations. The idea is to create final kiosk user account by unattended file passed to sysprep. And here is where I have number of challenges. I create user account user1 in oobeSystem pass. I setup autologon. So far this will work. On first boot it will autologon and go thru the whole first user creation experience. What I need it to do is to have customized user account settings.
Is there a way to provide that via some unattended process? I also need to run one time powershell script on first boot, that performs additional system setups and customizations. Quick test to create FirstLogonCommand in oobeSystem with that should create new folder and simple text file shows that it fails to run. Maybe it runs the command before the user account/session is fully functional, I do not know. The goal is to be able to run specialized powershell script once in context of the user1 account.
Any thoughts?
There's currently a bug with sysprep and Windows 10 LTSC 2021.
After running sysprep, Windows security breaks for all existing users at the time sysprep was run. It works correctly for new users, including the one created on the OOEB account screen. Only the UI becomes inaccessible for existing users, while features seem to work correctly.
To fix it, you can run the following command in PowerShell as admin:
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage
-DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml”}
It might show some errors, but it will work. This resets the security app which will fix the UI not showing.
Unfortunately, I don't know how to stop this from happening in the first place.
I noticed today that on windows 10
some apps in the folder C:\ProgramFiles\WindowsApps... are protected in some way other than just the access permissions.
When installing Microsoft.MicrosoftEmulator_1.1.39.0_x64__8wekyb3d8bbwe.msix or Microsoft.253890156C685_1.0.0.0_x64__8wekyb3d8bbwe.Msix
as well as it seams other apps from the store
the Folders for those created in under C:\ProgramFiles\WindowsApps\ have some additional write protection.
While a cmd prompt started as TrustedInstaller can create and delete folders in the apps that come pre-installed in the folders fo these apps this fails with an access denied error.
Taking Ownership of those folders and files as well as adding full access permission does not solve the issue.
With a cmd prompt started as system it is at least possible to create or delete folders but for the existing folders created by the package installer its still not able to create a file within those.
This protection remains in place even when the system partition in question is mounted by an other windows 10 system.
The only way I found to gain full access to these files is to mount the partition in a windows 7 installation.
So it seams to me that MSFT has added som additional layer or patronizing the administrators which needs to be understood and broken.
Any ideas how to get around this issue?
Well however the restrictions are implemented with this driver: https://github.com/DavidXanatos/IgnoreACLs you can gain access to everything everywhere.
With minor limitations, renaming of files in protected locations does not work and creating of directories.
Other than that, modifying, creating and deleting files and folders works fine.
Power back to the owners of the devices.
I created a Windows installer for a Client-Server program by using VS 2013 and InstallShield LE 2015.
I log in to a computer as Admin and run the installer. All works fine.
Then I modify the registry for Local_Machine for some keys to define the database location etc. for the program (this was done by the installation initially as well, but due to certain issues discussed in At each login the program tries to configure installation parameters in the HKEY_LOCAL_MACHINE registry, I removed the registry modifying section from the installer).
I then run the program by double-clicking the shortcut placed by the installer on the desktop and test it. All works well.
Then I log off the computer.
Another user with admin rights logins and clicks on the shortcut, and the problem comes: the program starts to reinstall itself!
Then it fixes itself and runs fine.
But If the first user logins afterward, she experiences the same reinstall operation so does the first user afterward ad nauseam!
So, even though the installer does not create any registry items by itself, somehow, as soon as the program accesses the registry, or whatever it thinks broken, the Windows OS intervenes and tries to repair whatever needs fixing.
The InstallShield LE does not allow setting shortcuts to be "Advertised Shortcut", or
I delete the shortcut created by the installer and recreate it manually after the installation and yet experience the same problem. So the nature of the shortcut possibly is not the cause.
This problem only happens for multiple logins to the computer. If many people login by using the same credentials, it never happens.
So, what's wrong? I studied many StackOverflow answers to resolve this issue with no success. Any help would be highly appreciated.
Stein gives a good set of instructions on how to diagnose problems with MSI programs in this StackOverflow answer. When I followed his instructions, I was able to check which component of my MSI program has a problem. It turns out, the serial bus controller library, MScomm32.ocx could not register under Win 10 properly. Once, I implemented the solution in this link, the above problem resolved and I could log in as two different users without initiating a reinstall process whenever the program icon was double-clicked to run.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.
I've built an installer for my application by hand (don't ask why). And I set up the registry keys for its entry in the add/remove control panel under HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall. And it works fine. I need it to be under HKCU so my installer will run on Vista without asking to be elevated.
The issue I have is that if a user installs using a domain account with a roaming profile, and then goes to a different machine, there's an entry for my software in the add/remove control panel with no information in it. I don't want it to appear there for roaming users, my app does not get installed in such a way that it will work in that circumstance anyway. Is there anyway I can setup that entry so my app won't appear in the add/remove? Or have I doomed myself to it by making the entry under HKCU? Thanks!
fwiw:Google Chrome installs the way you did, but also suffers from the same problem since it installs in the profiles "local settings\app data" directory, which doesn't roam [1].
Rather than fix the install\uninstall problem, would it be reasonable to have your app roam with the user? Is it small and xcopy installable such that you could install it under Doc & settings\Application Data some place, which does roam?
[1] http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dseb_ovr_wpeu.mspx?mfr=true