Mapping printers and drives through Group Policy Preferences

System admins have had to wait quite a while for Windows to provide them with means of mapping drives and printers without using a logon script. I started with mainly Windows 98 computers on a non-MS DC, then we got to XP and WS2003, but we were still using the scripts written in VBScript to set up the users. Then along came WS2003 R2, and with it a Print Management Console and Group Policy that could deploy printers, using an application called pushprinterconnections.exe. This seemed like a great way to solve at least half of the problem, anyway. It was supposed to be able to deploy the printers to both computers and users. We started to use it at our site and it could certainly deploy the printers to individual computers, but it didn’t seem able to manage sending them to individual users. So we just made the printer connections appear on the computer for all the users, and this worked out well for a while.

The main problem of using the Deploy Printer GPO, whether manipulated through GPMC or the Print Management Console, is that it is practically impossible to remove a printer that is no longer used. These printers will continue to appear in a user’s listings, even though they cannot be used for anything. You can’t delete them, and you certainly can’t print to them. The reason for this appears to be that pushprinterconnections or the other components of the policy-based printer deployment do not fully remove all of the registry settings that cause printers to be listed in the Printers folder. We opted mid-2008 to remove a group of computers completely by creating them with a complete new registry free of old printers and then use Group Policy Preferences, which is a new extension to Group Policy that is provided in the later versions of GPMC to deploy printer settings instead. As a bonus, GPP can also deploy drive letters, which enabled us to completely discontinue the use of logon scripts for this group. GPP can also set a default printer, which is much harder to do by other means. Finally, best of all, printers can be changed around, removed and renamed and so on. The default printer option is one that we can now set by location using a loopback policy, for users like pupils who move from one area to another. GPP is not accessed from the Print Management Console, it is accessed from GPMC only.

All good. But I still have a chunk of users with PMC deployed printers that I want to change over to GPP based deployment. First thing is to remove the GPO that deploys the printers, of course. Then I needed to clean out each user’s registry to remove the old printers, and the keys I needed to delete are in HKEY_CURRENT_USER\Printers\Connections. There you’ll see a subkey with the name of every printer that is pushed by the PMC based deployment system. Delete these subkeys and reboot, and your old printers will finally disappear. Then implement the use of GPP to deploy printers to your users. For more information about Group Policy Preferences, read this Technet Magazine article.

UPDATE:

• You may need to delete the same keys from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print instead of the HKCU path shown above. The name of each subkey looks something like ,,servername,printername e.g. ,,DC01,Brother HL1240.
• Windows XP computers may need to have the Group Policy Preferences Client Side Extension Update installed.
• Windows Vista clients may have difficulty processing a GPP for printer settings. I’m looking into this at the moment.

UPDATE 2:

• A CSE may also be needed for Windows Vista. See the link above to obtain it.
• Vista computers don’t appear to automatically deploy drivers. I’m looking into whether the old Group Policy can be used just to deploy drivers. This is the main reason why your printers will not deploy in Vista, if you use a GPP to deploy them, even if they are network printers. You may also experience a situation where the default printer setting is repeatedly lost in Vista. I recommend you install your default printer manually as a local printer.

UPDATE 3:

• Windows Vista handling of PMC printer deployment appears to have been improved. Removing printers from the GPO will lead to their removal from computers that deploy the policy. However, you may have to set the following GPO setting to ensure this happens: Computer Configuration\Administrative Templates\System\Logon\Always wait for network at computer startup and logon = Enabled. My testing appears to suggest that the GPO containing the printers should be deleted and a new GPO created, rather than just altering a GPO. You might consider deploying each printer in its own GPO which makes it easy to delete a printer just by deleting the GPO.

Re: Installing Moodle 1.9 on WS2008 x64, IIS7, PHP 5.2, Postgresql 8.2 (pt 1)

After looking into this in more detail I'm starting to think the reason for the problems is trying to install onto a domain controller. There are so many instances where people have had no trouble at all with just basic steps, all the steps I did, getting PHP (even just the 32 bit release) working on x64 WS2008 IIS7.

One of the issues with a DC is joining a WS2003 domain which we have because the other DC, which at the moment holds all the master roles, is a WS2003 DC. This causes problems with the IIS_IUSRS accounts / groups that IIS makes use of. In any case, I want to provide access to Moodle from offsite, and so it makes sense to look at running it on the gateway server for our site, which will be accessible externally by default, rather than providing a connection through this server to another server on our site. Another possible hiccup is that this server is a WSUS server. That means WSUS makes use of the default website on port 8530 to serve some of its update files (specifically selfupdate). This shouldn’t affect the default web site, but it could nevertheless produce unintended consequences.

The next step I plan is to try PHP by itself on a test WS2008 server I have around here that is just a member server and not a DC (and has not ever been a DC either). If that works, I'll change my deployment plan and put Moodle onto the gateway server instead. I’m still planning to use Postgresql on this box, but as a standalone database server for some specific applications using ODBC (hopefully).

WELL: I was surprised at how simple and quick this was. Literally within half an hour of posting this message, I have PHP running on a WS2008 x64 IIS7 server. The key steps being (refer to the original posts for details):

• Run the installer and select the IIS ISAPI module option in the installation
• Configure IIS7 with the HandlerMapping. Also, make sure you view the list of HandlerMappings as an ordered list, and that the entry for PHP files appears higher than any handler which uses * as the filetype. When I put in the PHP ISAPI mapping, it automatically appeared at the top of the list so no problem there.
• Configure the ISAPI / CGI restriction entry.
• Change the settings for the Application Pool for your website. In my case, using the default website, I am using the DefaultAppPool, allowing 32 bit applications to run.

And that’s it. Without any PHP configuration whatsoever, a phpinfo call comes up as expected. Voila.

However, I’m not 100% convinced there are not going to be more problems on the gateway server. This x86/x64 compatibility is a real bugbear. I think that I have to stick with x86 for compatibility with Postgresql, which is not yet available as a x64 Windows build. But the server has to be x64, and it’s going to have all of this other stuff running on it in native x64 mode, like Exchange, ISA and TSGS. We are just going to have to see what that will do when it’s all set up. I’m also still trying to debug the problem in the DC, which should be easy to do if I can get failed request tracing working and having a bit more playing with the permissions. At the moment I am not going to do any more Moodle installation until I have got the new server and set up stuff on it. The real question here is whether setting the AppPool to enable 32 bit will stop 64 bit apps working. Hopefully IIS will allow this to be set on a per-pool basis and then I can set up a custom app pool for PHP.

Installing Moodle 1.9 on WS2008 x64, IIS7, PHP 5.2, Postgresql 8.2 (pt 1)

Moodle is a free Learning Management System that is supported on various platforms. A lot of these big open source packages are primarily developed for Linux/Unix these days. If you are very blessed then someone has gone to the effort to produce a Windows port or installation package. Happily, that is becoming more and more common. We have just taken delivery of a new server running Windows Server 2008 64-bit and it comes with IIS7, which is a whole lot different from IIS6. I previously got PHP 5.2 running on IIS6 without much difficulty, but naturally, MS must make IIS7 new and more tricky to set up. These instructions that you can find on the web are now out of date as they apply to IIS6. There’s also a new choice in IIS7 and that is whether to use the ISAPI module of PHP or a new module provided by MS called FastCGI. I haven’t looked into this much yet and am concentrating on ISAPI for now because of my familiarity with it. An important point to note is that PHP and Postgresql are 32 bit applications. In the case of PHP, in particular, this may require IIS7 to have a specific configuration for 32 bit compatibility. Postgresql has finally (in my long experience of it) moved to a native Windows port which was historically not provided for by the developers. PHP has been available for IIS for some years but I found 4.x impossible to get working, whereas 5.x was relatively straightforward.

Installing a system like Moodle is a big project because it relies on all the various components and extensions which have to be got working together. It’s something I would prefer to pass the buck on. If only :). Although, I did get Wordpress working nicely on the server last year (which was what used PHP at that time, as well as MySQL which was also relatively trouble free. However another project I looked at, which used Apache Tomcat, turned out to be too much trouble. It was a nice idea, but getting all the bits working together was just too difficult for someone not an expert in Java in particular, and maintaining it would be just as challenging. This year I’ll have a staff member working with me at our site who is an experienced DBA, and he’ll hopefully have a good grasp of running Moodle, so I think that will make a big difference to the use of the LMS in our site.

What I’ve been able to work out from translating the old IIS6 instructions for installing PHP on IIS7 on WS2008 x64 goes something like this:

1. Install PHP:
1. Install PHP 5.2.8 using the supplied installer. At this stage, I skipped installing PECL.
2. Set up a Session state folder and change php.ini to point to it.
3. Skipped installing extensions at this stage
4. Checked the PHP path is set in the PATH environment
5. Checked the Registry key points to php.ini
2. Configure IIS: (ISAPI module)
1. In IIS7 the first step is Handler Mappings. You add a Script mapping for the php5isapi.dll file for the extension of *.php. Set the Request Restrictions as follows: Restrict the verbs to GET, POST, HEAD, and set the Access level to Script.
2. Also, go to ISAPI and CGI Restrictions and add an entry for the same ISAPI DLL to allow it to execute.
3. Finally go to ISAPI Filters and add another entry for that DLL. This particular step is one I’m not terribly clear on the necessity of, but sometimes it is apparently necessary.
3. At this stage trying to load a simple php file got me to a HTTP 404.17 error message, “The requested content appears to be script and will not be served by the static file handler”. I did a bit of poking around, and then tried going to Application Pools and enabling 32 bit applications on the advanced settings of the DefaultAppPool.
4. This now gets me a “HTTP 500.19 - Internal Server Error. The requested page cannot be accessed because the related configuration data for the page is invalid.”
5. Microsoft suggested giving IIS_IUSRS group permissions to read the config file for the server. I set this up, but it hasn’t changed the error message from 500.19

You can imagine we get grumpy because there are so many security related changes to these systems with Vista, with WS2008 and it makes for a steep learning curve and a whole lot more stuff we have to learn to get things running. Under WS2003, Moodle would practically be all installed by now. I am highly tempted to look at one of the other options for getting PHP running. I think I will just give it one more day to see what I can come up with on this option, and then try one of the other options, like IIS6 backward compatibility mode, or FastCGI.