I recently managed to cause myself a huge headache when removeing some software via group policy.
The worst part is, I only have myself to blame as the software was wrapped by me using Masai Installer.
If software uninstallation (or installation for that matter) goes bad, then a dialog window will open asking for some sort of input, which should never happen during silent installations.
If this happens while Windows is installing / uninstalling managed software, then Windows will hang and the only way to avoid the installation is to reset the computer.
The way around this is to make sure that you test the MSI by installing and then uninstalling.
The best way is to use these commands:
msiexec /i msifile.msi /qb
msiexec /x msifile.msi /qb
Of course, replace msifile.msi with the name of your MSI installer.
If the MSI installs and uninstalls without any prompts for input, then you know that it will deploy correctly through group policy.
If there is a prompt, then you need to work out how to prevent the prompt appearing during the installation.
As I’m always forgetting these, I thought I’d make a note.
When installing software on a Microsoft Terminal Server, you need to set the server to be in installation mode to support folder virtualisation for users.
One way to make sure that this works is to install any new software through Add/Remove Programs, and then ‘Add New Programs’
A quicker way is to simply use the command line:
change user /install
This puts the server into install mode. After this, install any software that you need to install.
Once done, put the server back into execute mode:
change user /execute
This will switch the user session back to it’s normal mode which is used for running applications.
Getting roaming profiles working on Windows Servers is a very simple process, and I generally include this in a script when creating users for the first time.
Here’s a quick ‘how to’ for those that are interested, based on a Windows 2000 or Server 2003 network.
Step 1 – Decide where you want the profiles to live on your file server
- Log on to the Windows server as an administrator
- Open the drive where you want your profiles the be stored for the user accounts. It’s worth noting that by default, Windows user profiles stores Application Data, My Documents, Cookies, a few other folders and the profile itself. Needless to say, if you are using the defaults, make sure that you have enough drive space.
- Create a folder where you want your profiles to live. I generally store user profiles in D:\Users on a server. Make sure that the folder has user read privileges.
- Right-click on the folder you have just created and click ‘Sharing…’. Call the share ‘Users’ and give all users full access to the share.
Step 2 – Configure a user profile to roam
- Open ‘Active Directory Users and Computers’. You can find this in the ‘Administrative Tools’ folder on the start menu
- Find the user that you want to set up a roaming profile for, and double-click
- Click on the ‘Profile’ tab
- In the ‘Profile Path’ field, enter the network path to the Users share, and then add the username to it. (eg. \\myServerName\Users\John)
- Click ‘OK’ to apply the changes to the user account.
Step 3 – Check that the profile is saved back to the server
- All we need to do now is check that the profile is going to be saved back to the server correctly. So log on to a client workstation with the user that we have just been tampering with. Once logged on, log off again.
- On the server, goto the User profile folder (D:\Users\) and have a look. In our case, the user was called ‘John’, so you should see a folder called ‘John’. The profile is stored inside here. Well done!
A few pointers
- Some of the settings in the profile tab directly conflict with the profile path and some other group-policy settings. Don’t be tempted to use the ‘Home Folder’ option if you are using profile path
- You can replace the username with %username%. This will automatically put the username of the user in for you. This is especially handy when you want to change the path of multiple users at once.
- If you have more than one domain controller, and the profiles and stored on there servers, you can use %logonserver% instead of \\myServerName. Just bear in mind that you should be using file replication for this to be useful.
- You may not automatically have access the the profile folder that has been created. If you logged on for the first time in Windows XP SP2, then the default folder permissions will lock administrators out of the profile folder. You need to change a setting in the policy if you don’t want this to happen.
- When Windows 2000/XP/Vista logs onto a network, the entire user profile is copied to the local machine. When you log out, the profile is copied back to the server. If the user has masses of data in the profile, then you should be using folder redirection to move folders
As Microsoft have released the new policy template, ADMX with with Vista – it’s about time I looked into converting our Centaur Systems policy template to the new ADMX format to see how the process goes.
Thanks to the ADMX Editor available from Microsoft, the process is quite straight-forward.
- Install and run the ADMX editor
- Click ‘Generate ADMX from ADM…
- Click ‘Yes’ to load the new ADMX file into the editor.
- Finally, select your new ADMX file and click ‘Save As…’
The editor will save two files. One will be your ADMX file, and another will be a language file (ADML). This contains the strings that you have used in the ADM file.
Now, if you want to use the ADMX files over a Windows 2000 / 2003 network, then that’s no problem either!
- Open the SYSVOL share on a domain controller (preferably the PDC-emulator role if you have multiple servers)
- Open the Policies folder and create a new folder called PolicyDefinitions
- Copy your ADMX files to the new folder (and the ones from %systemroot%\policydefinitions if you want to include the standard Vista ADMX files)
- Copy the relevant language files into a subfolder (in my case that’s en-US)
As soon as these policies are available over the network, Windows Vista will ignore the local ADMX files and get system values from the server copies instead. Woo!
I noticed that some files were disappearing on one of the Servers the other day. A few people had noticed. And it finally happened to me. I was roaming through my ‘My Documents’ folder when I noticed that folders that shouldn’t be empty were.
Checking out the KnowledgeBase, I discovered that if your profile folder is the same as your home directory, then the server sometimes decides that the best thing to do is delete the files.
Although it turns out that if you use a subfolder in the home folder this resolves the problem.
I certainly hope so. I don’t think too many people will be impressed with files randomly disappearing…
I’ve been having problems with the Tally 8006e and 8024 running on Windows Server 2003. On a couple of systems I’ve found that the drivers seem to knock out the Windows spool. Whenever it tries to print, an error message pops up saying Unable to create print job.
The fact that it doesn’t even seem to try was quite frustrating. Luckily I was fixing another problem on one particular server and needed to reboot. On startup I had a more useful message Spooler subsystem app has encountered a problem and needs to close. I should have really checked the system log, but this problem had been around for such a long time, I wasn’t sure if it would actually still be there.
So it was with some fortune that I managed to find this new message on the KB article 810894.
Follow the instructions and it will remove the printer drivers and allow you to add new printers afresh.