Tuesday, November 20, 2012

Windows 7 Customizing and Copying Default user profile with Windows Enabler


In past Operating Systems, such as Windows XP, if you wanted to customize the default user profile’s settings, customizations, wallpaper, screen saver, etc that new users would have applied upon first logging into a machine, you’d simply:
[Log in as a local administrator] > Go into User Profiles > [select your customized user profile with the settings you want to be default] > click Copy To button > [choose the location of the Default User folder]
Presto! The next time a user logs in (who doesn’t already have a profile created) will have the customizations applied.
In Windows 7 however, Microsoft decided to disable the ability to copy profiles to the Default profile using this classic method. In fact, the only profile you can copy from is the “Default” profile itself! This prevents you from customizing a profile, and copying it anywhere.
Copy To button operating in Windows XPWindows 7 Copy To button  disabled
I spoke with a Microsoft representative who specializes in imaging. She said the only supported method is to use sysprep with the <copyprofile> tag in the unattend.xml file, and running:
sysprep /generalize /unattend:unattend.xml
To make it easier, she suggested MDT2010.
I hope all is well with you! With respect to customizing the default user profile in Windows 7, the only supported option is to use the copyprofile setting in the unattend.xml. Are you using MDT to build your image? If so, enabling this functionality is very simple. Essentially, you would open up the task sequence you are using to create the image and edit the unattend.xml (associated w/ that task sequence) to enable the copyprofile setting. In your task sequence, you can then add a script (or scripts) to customize things like your corporate screen saver, desktop wallpaper, etc. Did I provide you with these scripts when you attended the deployment HOL? If not, let me know and I can stage them on a share for you to download. If you don’t have your customizations scripted you can insert the pause task into your task sequence so that after the OS and apps are installed you can manually make your customizations. After you complete this process, the task sequence will resume and it will automatically sysprep the image (with the copyprofile setting enabled) and capture it as a WIM image.
These scripts can be used inside and outside of MDT 2010 to automate customizations made to the profile. Download MDT 2010 here.
Sysprep? Well this is good and all if I were going to be implementing Microsoft’s deployment and imaging solutions, but all I wanted to do is customize the default profile. There should be no need go through these complexities for something so simple. Read on for the Solution!

Solution!

Rather than spending hours trying to create/generate an unattend.xml file, performing various reboots, and running into limit for the /generalize switch (you can only generalize 3 times, or up to 9 times with the <SkipRearm> tag), among other headaches, and limiations (such as only being able to copy the administrator profile, then dealing with the deletion of the profile), I decided to think outside of the box.
After browsing various forums, I remembered an OLD utility called “Windows Enabler”. I posted my solution to the Microsoft Technet online forums, and everyone was ecstatic. It worked!
(Click here to visit the post, do a find for my name “Imfusio”. Below that you can see everyone’s testing, and verification procedures.)
1. Download a little freeware program called “Windows Enabler 1.1” Download here.
(It’s a handy little portable utility I keep on my thumb drive and network utilities folder. All you need is the “Windows Enabler.exe” and “EnablerDLL.dll” together in a folder.)
2. Run Windows Enabler *as Administrator* on the Windows 7 machine, and a little blue & white icon will show up in your system tray.
3. Bring up the “Users Profile” window, and select the profile you wish to copy where the button is grayed out.
4. Click on the Windows Enabler icon in your system tray, and it should say “On
5. Click once on the “Copy To” button, and it should un-gray the button. Click the Windows Enabler icon again to turn it off.
6. Now, you have your Copy To button working! Copy the user profiles as you normally would, and try logging in as a new user on the machine.Click to turn ONClick again to turn OFF
Copy to button is now enabled and functioning!

Potential Issues

I tested this method, and it appears functional with only minor issues, just as with XP (for example, the My Documents kept the name of the original profile, ie “temporaryuser’s Documents” while logged in as another user). The Windows 7 resource kit mentions DJs (Directory Junctions) that can become corrupt, and other registry data that is not copied when using this technique, or any other method than that which is supported (sysprep method). However, I was able to copy a profile, and log in with a new user, and everything looks good! I had saw no visible problem with the Directory Junctions, or anything else. I currently have plans to put an image with user profiles created from this method through QA in a corporate environment. I will make note of any issues we run into.
The known issues are very subtle. We’ve been using this process with Windows XP, many of us not even knowing that using that function was not supported, and that issues existed when using this method. However, we never ran into many real problems with it. It is just now that the Copy To button is disabled that we are aware of the potential side effects.
Windows XP did not support manual copying of profiles either. Here are issues to look out for when using this method.
It is very old procedure from NT4, when the shell was much simpler.  The shell is more complicated for Windows 2000 and higher.  This process will copy settings that should not be copied to the default user profile.  It may seem to work but you will find subtle problems.  Windows XP and later have made those subtle problems more visible.
The manual profile copy process can cause issues such as:
  • 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.

Thursday, November 15, 2012

You receive an error message when you try to open a file type that was blocked by your registry policy settings in Word 2010, in Word 2007, or in Word 2003

You receive an error message when you try to open a file type that was blocked by your registry policy settings in Word 2010, in Word 2007, or in Word 2003

http://support.microsoft.com/kb/922849#w2003


RESOLUTION

Use a trusted location, or create an exempt location

To do this, follow these steps, as appropriate for the version of Word that you are running:
  • In Word 2010, if you trust the file that you want to open, you can open that file even if the file type is blocked by the registry. You can override the registry policy settings by moving the file to a trusted location.

    For more information about how to create, to remove, or to change a trusted location for files, visit the following Microsoft Web site:
  • In Word 2007, if you trust the file that you want to open, you can open that file even if the file type is blocked by the registry. You can override the registry policy settings by moving the file to a trusted location.

    For more information about how to create, to remove, or to change a trusted location for files, visit the following Microsoft Web site:
  • In Word 2003, there are no trusted locations. You can create an exempt location to override the registry policy settings. To create an exempt location, follow these steps:

    Click here to view or hide detailed information

    1. Exit Word 2003.
    2. Click Start, click Run, type regedit in the Open box, and then click OK.
    3. Locate and then click one of the following registry subkeys:
      HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common
      HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Common
    4. Point to New on the Edit menu, and then click Key.
    5. Type OICEExemptions for the name of the key.
    6. Point to New on the Edit menu, and then click String Value.
    7. Type a string name, and then press ENTER. For example, type ExemptDirectory.
    8. Right-click the string name that you typed in step 7, and then click Modify.
    9. In the Value data box, type the path of the directory that contains the file, and then click OK. For example, if your document is in the C:\My Documents folder, type C:\My Documents in the Value data box.

      Note You must create the folder. Any subfolders are not automatically exempted. For any additional folders that you would like to make exempt, repeat steps 6 to 9 by creating string values such as "ExemptDirectory1," and "ExemptDirectory2."
    10. On the File menu, click Exit to exit Registry Editor.



Tuesday, November 6, 2012

Comparison of network monitoring systems

Which monitoring software is right for you? Take a few seconds and easily compare several top rated computer monitoring programs with a side-by-side features comparison


The file on link below contains comparison in general and technical information for a number of network monitoring systems. Please see the individual products' articles for further information.








Monday, November 5, 2012

VB Scripts and UAC elevation


With User Account Control (UAC) enabled in Windows 7, one needs to open an elevated Command Prompt in order to run scripts under administrative privileges. Although the elevated Command Prompt accomplishes the task, the question How to run as script under elevated privileges/admin privileges

1. without using the Command Prompt? 
2. without user being admin on machine?

We can achieve the same by GPO which can deploy application etc. using system account but it doesn't solve the purpose where only selected users need to install applications with no admin rights on machine.

Scenario in my organization

We have intranet site in our organization with downloads page for installation of any software's for users.

Downloads page has a link to .vbs script which installs the software from local available repository when users click on the link
Problem is that users with no admin rights on local machine cannot install software especially in windows 7 as most of our users have been migrated to windows 7 with no administrator rights.

Solution: 

We created a script which can install the software on any machine with no admin privileges

We encoded the final script to protect from users

Below is the script:
******************************************************************
Option Explicit

Dim MyArr, i, IPaddress, tstr, Subnet2, Subnet3
Dim SCSserver,MapPath,oWshShell

Dim strArgs, strAdminUser, strAdminPass
Dim objFSO, wshNetwork, strComputer, objShell, strCommand

Set objFSO = WScript.CreateObject("Scripting.FileSystemObject")
Set wshNetwork = WScript.CreateObject("WScript.Network")
Set objShell = WScript.CreateObject("WScript.Shell")

'Enter your domain admin user id/password or account with admin privelliges on your organisation machines
strAdminUser = "domain\userid"
strAdminPass = "password"

Dim WSHShell
            Dim objNTInfo
            Dim GetComputerName

            Set objNTInfo = CreateObject("WinNTSystemInfo")
            GetComputerName = lcase(objNTInfo.ComputerName)

            Set WSHShell = WScript.CreateObject("WScript.Shell")
           
If WScript.Arguments.Count < 1 Then
      Call Normal_User_Commands
ElseIf WScript.Arguments(0) = "AsAdmin" Then
      Call Admin_User_Commands
Else
      MsgBox "Unknown Argument received"
End If

Sub Normal_User_Commands
      'MsgBox "Running as initiating user"
      strComputer = GetComputerName
      'Download psexec.exe and copy it on network as we are using psexec.exe
      strCommand = "cmd /c <Path for psexec.exe> \\" & strComputer & " -i -u " & strAdminUser & " -p " & strAdminPass & " wscript.exe <complete path for your script which installs application/software.vbs> ""AsAdmin"""
      objShell.Run strCommand, 0, True
End Sub



Sub Admin_User_Commands
      'Now running as Administrator on the target machine
      'MsgBox "Running as Admin"
      strCommand = "notepad.exe"
      objShell.Run strCommand, 0, True
End Sub
********************************************************************