When you have the Group Policy Preference (GPP) Client Side Extensions (CSE) downloaded you'll notice that they are not (yet) in the .MSI format - so using Group Policy Software Installation (GPSI) is not possible. Bummer, right!?
We have .EXE files for Windows XP/2003 and .MSU files for Windows Vista... But that's not the only thing we need to think about. Before "deploying" these things to the clients on the network we need to know the OS version (XP/2003/Vista), the OS architecture (32 or 64 bit), the Service Pack Level, and whether or not the Group Policy Preference Pre-requisites (WmlLite - http://support.microsoft.com/kb/914783/en-us) are installed.
To make all this pretty easy I've created a "demo" script for deploying the GPP CSEs using Startup Script - or a manual launch (in admin context). My good friend Jeremy Moskowitz asked me to do this - so, a couple of hours later the "demo" - or "beta" - script is public (download below)...
Note: I haven't been able to test in all scenarios yet, but I *think* they are all covered pretty well by now. Please report back if you find any problems - any feedback is welcome!
Download the VBS script right here!
NB! You might need other language version for the XmlLite GPP CSE Pre-requisites, so watch out!
Running the script in your production network is on your own risk. The code is delivered "As Is" - totally free of any charge. No strings attached.
I hope this works out nicely for you!
.
Written by Jakob H. Heidelberg on February 29th, 2008 with comments disabled.
Read more articles on Client Side Extensions and Jeremy Moskowitz and Windows Vista and Windows XP and download and gp preferences and group policy and group policy extensions and group policy preferences and microsoft and scripting and windows server 2003.
This information is widely available but very useful so here is how I do it!
1. Run REGEDIT on any domain workstation logged in as a domain admin
2. Hit Alt ‘f’ than ‘c’
3. In the Select Computer search box, type its name in the dialog box (or of course browse for it)
4. In the remote machine’s registry browse to the following key: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server
5. Find the value named ‘fDenyTSConnection’ (REG_DWORD). Change the value data from 1 (Remote Desktop disabled) to 0 (Remote Desktop enabled).
6. Close REGEDIT.
7. Of course you will need to reboot the remote machine for the change to take effect. My favourite way to do that is to open the command prompt and type ‘shutdown –i’, fill in the appropriate fields and away you go.
Written by Odd-Magne Kristoffersen on February 19th, 2008 with comments disabled.
Read more articles on Windows Vista and Windows XP and windows server 2003.
If you have ever tried defining the Security Options policy setting called: "Interactive logon: Message text for users attempting to log on", you may have had some difficulties formatting the message the way you wanted it. This blog is about "how to" workaround a minor bug in the GPEDIT tool...
The issue:
First things first - the Group Policy setting is located here:
"Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\"
The value is a Multi-String registry value that allows you to make multiple lines in the message. The message pops up right after a users hits Ctrl+Alt+Del as a general warning to the user before actually logging on. But, unfortunately the formatting isn't as perfect as it could be.
What happens is, that carriage returns are lost after formatting this "pre-logon message" with GPEDIT, imagine you would want a message like this (see Figure 3):
--->
I don't know why this should be so hard? Jump next line please...
Let's do a comma, and continue the line...
Line number 4 is ready, but let's jump line 5 & 6 now...
Line 7 finishes up this story!
<---
Such a message would end up as (see Figure 5):
--->
I don't know why this should be so hard? Jump next line please...
Let's do a comma, and continue the line...
Line number 4 is ready, but let's jump line 5 & 6 now...
Line 7 finishes up this story!
<---
So, basically the problem is: line feeds/carriage returns/empty lines disappear completely!
You can actually see this within the GPEDIT GUI, but only if you hit "Apply" before "OK" - if you just hit "OK" after typing in your message you cannot see that it's actually changed by GPEDIT (so you think the formatting is working as it should). I tested this behavior with GPEDIT on Windows XP SP2 (local policy), Windows Server 2003 SP1 (domain policy), Windows Vista SP Pre-RC (local policy) and Windows Server 2008 RC1 (domain policy).
Figure 1 - I typed in my message with the format I wanted:
Figure 2 - I clicked Apply, and the formatting was changed:
If I had just click OK I wouldn't have noticed the change - anyway it's a bit annoying, right?
Solution/Workaround:
The solution I came up with is to modify the policy file directly/manually using Notepad. The file is located here:
"\\DOMAIN.local\SYSVOL\DOMAIN.local\Policies\{GPO-GUID}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf"
Within that file we have the relevant registry value, called "LegalNoticeText":
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeText=7,I don't know why this should be so hard? Jump next line please...," ",Let's do a comma"," and continue the line...,Line number 4 is ready"," but let's jump line 5 & 6 now...," "," ",Line 7 finishes up this story!
Notice the " " (<quote><space><quote>) sequences, which are the same as empty lines.
This is the relevant line from a working GptTempl.inf file (the correct syntax written manually), and it actually works great:
Figure 3 - Pre-logon message on a Windows Server 2003 SP1 Domain Controller:
Figure 4 - The above inserted GptTmpl.inf line also works for Windows XP SP2 in the same domain:
So, this proves that the INI file can actually be correctly formatted so clients (tested w/WS2003 SP1 and XP SP2 in a domain) can show the message perfectly. Please notice that the behavior is similar with local policies, but my testing has been focused on domain environments so far.
If you try to modify the working policy setting using GPEDIT again - after changing just a tiny bit (or just hitting OK to an existing setting) within the GPO the formatting/syntax is ruined again unfortunately (when GPO is saved by GPEDIT)! Look here what came out of it when I tested it:
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\LegalNoticeText=7,I don't know why this should be so hard? Jump next line please...,Let's do a comma"," and continue the line...,Line number 4 is ready"," but let's jump line 5 & 6 now...,Line 7 finishes up this story!
Notice the " " (<quote><space><quote>) sequences are gone! This gives a wrong result (no empty lines) when clients get the pre-logon message.
Figure 5 - The formatting is lost (or wrong) when GPEDIT does the job:
Please notice, if you're testing this you will have to define an additional policy setting for it to work, namely the "Interactive logon: Message title for users attempting to log on" setting.
Figure 6 - The title must be set for pre-logon message to appear
Conclusion
So, my conclusion is that (existing version of) GPEDIT doesn't modify the GptTmpl.inf file properly (or the registry for local policies for that matter) - for this particular value at least... My best guess is that it doesn't handle the quotes (") correctly, but I can't be 100% sure. A bug report has been made for Microsoft - so hopefully it will be fixed before the final release of Windows Server 2008 and the Remote Server Administration Tools (RSAT).
However, as mentioned you can make it work with a workaround like this: Just perform the GptTmpl.inf (below SYSVOL) editing manually, make a backup of the file when it's perfect - and never touch that GPO with GPEDIT again... Until Microsoft releases an updated version of GPEDIT anyway.
Related KB articles out there:
KB 330618
KB 238149
Technet article
.
Written by Jakob H. Heidelberg on November 30th, 2007 with comments disabled.
Read more articles on RSAT and Security and Windows Server 2008 and Windows Vista and Windows XP and gpedit and gpedit.msc and group policies and group policy and microsoft and sysvol and windows server 2003.
This tutorial assumes that you’re running Windows Deployment Services and want to update the default BOOT.WIM file to enhance platform compatibility, but the processes for injecting extra drivers into a WIM file are exactly the same for ANY WIM-based image.You’ll need a full install of the WAIK, as it contains the necessary tools to manage WIM files. This can be done on any system, but if you’re running WDS it will install properly on the WDS server. Insert the DVD and select “Windows AIK Setup†and install WAIK.
Next you’ll need to create a folder to easily modify BOOT.WIM. I found it easiest to create a Temp folder, and then two more folders within that called Mount and Drivers. Then copy BOOT.WIM from the Vista DVD to the TEMP folder and rename it CUSTOMBOOT.WIM.Now download the drivers you need, and extract them to \Temp\Drivers.You’re not after DOS drivers – remember that this is Windows PE 2.0 so XP drivers are the best ones to use (or Windows Vista, if they’re available).WinRAR is a great tool for extracting the contents of an EXE while maintaining the folder structure – this is very important as you need to be able to get at the INF driver files.Once that’s done, go to the Start Menu, Microsoft Windows AIK, Windows PE Tools Command Prompt. This loads a command window with the PE tools IMAGEX, PEIMG and OSCDIMG loaded into the path, which makes life much easier.
Navigate to \Temp and type in:
imagex /info DRIVE:\Temp\customboot.wim
Where DRIVE is the appropriate drive letter. This checks the CUSTOMBOOT.WIM file and lists the images contained within it.
There are actually two images, but the one we want is the Longhorn Setup image – number 2. Now type in:
imagex /mountrw DRIVE:\Temp\customboot.wim 2 DRIVE:\Temp\Mount
This mounts image 2 of CUSTOMBOOT.WIM into the \Temp\Mount folder in read/write mode. You can navigate to this folder and browse the contents and make any changes you like.
Now go back to the command window and type in:peimg /inf=DRIVE:\Temp\Driver\FOLDER\*.inf /image=DRIVE:\Temp\Mount
Where FOLDER is the appropriate folder which contains the INF driver files. This injects the drivers straight into the mounted image. You can manually specify which driver is to be installed, or just use the wildcard to install all the drivers found in that folder. Repeat this process for all the drivers you want to install.
Once that’s done, type in:imagex /unmount /commit DRIVE:\Temp\Mount
This unmounts the image from the \Temp\Mount folder and commits the changes you made. Do NOT forget the /commit statement or you’ll have to do the whole thing all over again. Not fun.Now go back to the WDS console and right-click on the boot image, then select Disable. Right-click again and select Replace Image, then browse to \Temp\CUSTOMBOOT.WIM. This will replace the contents of BOOT.WIM with the updated CUSTOMBOOT.WIM. It doesn’t erase BOOT.WIM, and the boot image will still use the original file, but the extra drivers are now loaded into the Longhorn Setup image. Being able to replace the image means that you can maintain an offline master boot image, so you never need to directly work with the WDS boot image.Unlike RIS where any such change required a restart of the service, WDS accepts this change on the fly. Connect your clients to the WDS server and they will use the updated setup image with the incorporated drivers. In my setup, both problematic platforms worked perfectly with the custom boot image.News Source: www.apcmag.com
Written by Odd-Magne Kristoffersen on November 15th, 2007 with comments disabled.
Read more articles on Windows Server 2008 and Windows Vista and Windows XP and windows server 2003.
