Capturing User Profile when saving an image (sysprep) - windows

I have successfully captured an image using sysprep and can provision new machines from it, however all the custom user settings are missing (desktop shortcuts, chrome bookmarks etc...).
A more serious issue is that one of the applications I had installed fails on the provisioned machine unless run as administrator (due to the way it writes some files when being installed originally).
How can I ensure this profile information is preserved and I don't hit the permissions issue for the application?
I have been pointed at the following link (http://theitbros.com/sysprep-xp-sp3-copy-administrator-profile/) but it seems to be Win XP specific.

Profile information can be migrated to a new deployment using the User State Migration Tool (USMT). USMT is a free tool designed to help IT Professionals migrate files and settings to Windows 7 or Windows 8. USMT captures user accounts, user files, operating system settings, and applications settings and then migrates them to the new Windows installation. The TechNet articles ‘Step-by-Step: Basic Windows Migration using USMT for IT Professionals’ and ‘User State Migration Tool 4.0 User’s Guide’ are good places to start learning how to use USMT.
For your application issue, I would recommend using the Microsoft Deployment Toolkit (MDT) for your deployments. MDT can deploy your image and then install device drivers and applications to the machine automatically. These two video walkthroughs are specific to migrating from Windows XP to Windows 7 with MDT, and using USMT to migrate the user files and settings:
Part 1: Building the Deployment Environment
Part 2: Initiating the Install and Migrating the PC
There is also a Microsoft Virtual Academy 7 part course titled ‘Migrating from Windows XP to Windows 7’ that has two parts dedicated to using USMT to transfer user data and one part for MDT.
MDT can be downloaded here, and USMT is a part of the ADK which is a component of MDT.
Hope this helps,

The answer here wasn't very elegant (in my mind at least) but here is what I did to achieve the desired result:
Create the VM as usual (specifying the admin user during setup)
Create a new (non-admin) user and give them RDP access
Log in as the non-admin user
Install all the necessary software
Log in as the admin user, change the permissions for any files that were causing an issue to be readable by the non-admin user
Run sysprep as the admin and complete the process as detailed elsewhere
This gave me an image that I was able to provision VMs from. When creating the VM I specified the admin user to be created (but then never needed to login as the admin, as I would just login as my non-admin user that was created before). All profile settings for the non-admin user are preserved.
Hope this helps anyone else facing the same issue.

Related

Sysprep Windows 10 LTSC 2021

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.

Choose right Windows directory to install software and allow auto-updates

We are writing an installer for our Windows tool. As our tool uses an updater (wyUpdate) and we want that users WITHOUT Administator rights can performs updates. Which is the right directory to install the app to? The standard C:\Program Files requires Administrator rights, so we have discarded this option. After reading a bit on the Web, we have chosen AppData, i.e. C:\Users\USERNAME\AppData\Local.
Is this best practice? Or should we use another directory?
If you do not want to allow your users to mess with the installed program, you have to install it to a folder that needs Administrator privileges.
To allow an automatic update of such application, you need to develop/install a service that runs with Administrator privileges, which will update the installation. This is what Windows Update, Mozilla Maintenance Service, Google Chrome Elevation Service, Adobe Acrobat Update Service and similar services do.
If you do not want to implement a service, but you want the application to be used by all users of the machine, you need to install it to a folder that can be accessed by all users, yet does not need Administrator privileges. You can for example use C:\Users\Public. See also Is there a shared folder in Windows to which non-elevated users have write access?. You can use PUBLIC environment variable to resolve that path.
If the application is to be used by one user only, then you are ok with using C:\Users\Username\AppData\Local – {userappdata} in Inno Setup.
Related question: Deploying application with .NET framework without admin privileges

How to configure active directory in windows 7?

I just installed Remote Server Administrative Tools (RSAT) on windows 7, and turned features on as mentioned in the installation guide. Now the Administrative Tools have been installed and successfully listed in the All Programs list of start menu.
I want to set up a local network. I want to create users/passwords, and give them access to shared drives with permissions, etc.
My questions is:
How do I configure the Active Directory in windows 7 for the first time?
RSAT is to remotely manage an Active Directory environment. It's not for creating an AD environment.
If you want to create an AD environment, you need Windows Server (2003/2008/2012) and install the 'Active Directory Domain Services' or 'Active Directory Lightweight Directory Services' role. There are instructions online on how to do that.

How to find out what permission an application needs under Windows 7

Is there a way to find out what privileges my application needs in order to run in a Windows 7 environment?
I have a Delphi application that is using BDE and ODBC for database connectivity. This application works on most computers with Windows 7 running on a normal user account. However on some computers it only works on accounts with administrative privileges and is not working correctly on normal user accounts. I suspect it's a permission problem. The computers also are running in Active Directory.
I tried to find some informations using Process Monitor from SysInternals, however the output for me is too advanced. The process monitor log for two runs of my app (1. successful with administrative rights, 2. unsuccessfull on normal rights) had over 22k lines and i could not find the answer (needle) in the process monitor log (haystack).
What could i do to determine the privileges that my app needs in windows 7?
Use the Standard User Analyzer from the Microsoft Application Compatibility Toolkit.
The Standard User Analyzer (SUA) tool and the Standard User Analyzer
Wizard (SUA Wizard) both enable you to test your applications and to
monitor API calls in order to detect potential compatibility issues
due to the User Account Control (UAC) feature in the Windows® 7
operating system.
UAC, formerly known as Limited User Account (LUA), requires that all
users (including members of the Administrator group) run as Standard
Users, until the application is deliberately elevated, by using the
security prompt dialog box. However, not all applications can run
properly with the Standard User role, due to the application requiring
access and privileges for locations that are unavailable to a Standard
User.
Aaron Margosis has a tool called LUA Buglight that is designed to help track down issues related to privileges.
You can download the latest version from this blog post:
LUA Buglight 2.1.1 with support for Win7/2008R2 SP1
It is similar in concept to the MS Application Verifier. However, in practice I found LUA Buglight much easier to use and understand. Same with ProcessMonitor. It will monitor your process in a similar way but only report actions that failed as a normal user but succeeded as a admin user.
There is no documentation but it is simple to use. From the main GUI window select your Exe and let the BugLight program launch it. You need to be running in an Admin account with UAC enabled. Run your program though the steps that fail when you are not an admin. When you are done click on the Stop Logging button to see a report that lists what calls would have failed without admin rights.

How to generate a local user profile for a new user account in Windows?

I have created a new local Windows account and want to modify some of the personal data for this new created profile. But if this account was never logged in, the profile data is not generated and so I cannot modify it. I want to modify things like the NTUSER.dat to customize the Current User Registry and prepare things in the user’s personal folder.
I cannot use the default profile, because in my application it should be possible to create more than one local user account with different settings. And these Settings should not be used for the next new created user account.
Is there a way to initiate this generation process for the user profile folder?
If not, is there a good way to automatically logon this new created user, wait until the profile has been generated and then logoff?
The solution should be able to work under Windows 2000, Windows XP, Windows Vista and Windows 7.
(I am using .NET 3.5 / C#, but I am open to all kind of answers as well)
A friend could help me and found the answer. This doesn't work under Windows 2000, but it works fine for Windows XP and Windows Vista, I will test Windows 7 later, but I guess it should work.
http://support.microsoft.com/kb/196070/en-us

Resources