Problems when modifying the Default User Profile in Windows 7

When a user logs on to Windows 7 for the first time, there are some tasks that need to run. Be modifying the default profile, you may inhibit those actions from running. Below is a list of potential problems.

Their list of most frequently run programs is not cleared
Whether the user has been introduced to the Start menu (will be set to TRUE for the source account, but should be FALSE for new users). Windows Explorer does some special things the first time you log on to introduce you to the Start menu and other new features.
Whether the user is an administrator (and should therefore see the Administrative Tools, etc).
The personalized name for “My Documents” will be incorrect. All users documents folders will be called “Administrator's Documents”. This is documented in the Knowledge Base article “The Desktop.ini File Does Not Work Correctly When You Create a Custom Default Profile” (http://support.microsoft.com/?id=321281).
The default download directory for IE will be set to the Administrator's Desktop folder.
The default Save and Open locations for some application with point to the Administrator's documents folder.
Windows 7 Libraries are broken.

By manually modifying the default profile (or via a script) you are placing your Windows deployment into an unsupported state. Not good. Go to this article and take a look at option B. Note, that there are drawbacks to Option B. I support option F, Group Policy.

Comments

How to list all the AD LDS instances on a server

AD LDS allows you to provide directory services to applications that are free of the confines of Active Directory. To list all the AD LDS instances on a server, follow this procedure: Log into the server in question Open a command prompt. Type dsdbutil and press Enter Type List Instances and press Enter . You will receive a list of the instance name, both the LDAP and SSL port numbers, the location of the database, and its status.

How to run GPResult on a remote client with PowerShell

In the past, to run the GPResult command, you would need to either physically visit this client, have the user do it, or use and RDP connection. In all cases, this will disrupt the user. First, you need PowerShell remoting enabled on the target machine. You can do this via Group Policy . Open PowerShell and type this command. Invoke-Command –ScriptBlock {GPResult /r} –ComputerName <ComputerName> Replace <ComputerName> with the name of the target. Remember, the target needs to be online and accessible to you.

Where did a User’s Account Get Locked Out?

Updated: May 15, 2015 When this article was originally published, two extra carriage returns were add causing the code to malfunction. The code below is correct. My client for this week’s PowerShell class had a really interesting question. They needed to know where an account is being locked out at. OK, interesting. Apparently users hop around clients and forget to log off, leading to eventual lock out of their accounts. The accounts can be unlocked, but are then relocked after Active Directory replication. This problem is solved in two parts. The first one is to modify the event auditing on the network. The second part is resolved with PowerShell. The first part involves creating a group policy that will encompass your Domain Controllers. In this GPO, make these changes. Expand Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Account Management Double click User Account Management C...

Jason Yoder, MCT

Search This Blog