Are major peripherals becoming disposable?

Here’s a conundrum. I can buy a new printer from the likes of Brother for around $99. The official Brother drum for this printer costs $150. Maybe instead of buying that new drum I should just throw the printer away each time the drum wears out. The same goes for projectors which now typically have a very long bulb life up to 5000 hours. The issue there isn’t the cost of a new bulb, but rather the fact that after 5000 hours of use the projector could be considered worn out, or near to it, or uneconomic to justify the expense of the bulb.

When we get into more expensive printers, the cost of consumables is less proportionate to the cost of the printer, so it is more worthwhile to replace the items like a drum with new ones. Especially where you can buy third party consumables for a printer, as you can for most Brothers, since they are one of the few printer manufacturers who have not chipped and patented their consumables. This is all driven by cutthroat competition between printer manufacturers, to the extent that new printer prices are so low the manufacturers are selling at a loss. But we are the losers because we go out and buy a whole new printer instead of a new consumable and therefore are throwing away a large bulky printer which is bad for the environment.

At our school we buy Brother and the important reason for that is that their consumables are much cheaper. So are the printers. That is provided you can get a good performance from them. Lately I’ve had a lot of trouble with Brother’s drivers. I solved that by using HP drivers with the PCL5 compatibility. This works only as long as PCL5 adequately reflects all the printer’s features. And the printer is misidentified as to its capabilities. So it is a bit of a mixed bag all round.

Windows 7 Printer Installation Problems SNAFU

We have had a huge saga with printer installation when trying to automate that and control these through logon scripts or the various Group policy settings. Some way back a few years ago, in the days of Windows Server 2003 R2, Microsoft added the Print Management MMC tool along with the ability to manage printers using Group Policy. Later on, after buying out a company, Group Policy Preferences were added as a means of managing printers through Group Policy. Each of these has its own problems. The most serious problem you will encounter with Windows 7 is the dreaded hang when processing Group Policy Printers Policy. We have had numerous experiences where this simply freezes. I can leave a computer and come back the next day and it will still be stuck on this screen. This is a very debilitating experience for the user who cannot log on to their computer. All that will happen is that there will be entries in the events log talking about a long time spent processing Group Policy but when you try to find help to solve this problem there will not be any to find.

Microsoft has made a complete dog’s breakfast of centralised print management for domain administrators, although the early Print Management MMC approach that came in Windows Server 2003 R2 was a promising start. It is mainly the issue that the limitations of this, in particular removing printers which does not actually work properly, has been compounded by the further problems when using Group Policy Preferences, which leads to the situation  mentioned above with the logon freeze. In short the possibilities of being able to effectively centrally manage printer installation in Windows 7 have been kneecapped by what is now becoming a typical Microsoft cost cutting approach to resourcing these capabilities adequately. Therefore the only real option is to return to login scripting to install or remove printers, although this can also be managed through Group Policy settings.

I have started out by using a Powershell script, as Windows 7 / Server 2008 R2 has built in support for these in GPOs. Here I ran into the dreaded black screen after logon where the computer appears to freeze. Using some of the more reliable GPP settings like pushing across the registry key for DelayedDesktopSwitchTimeout and setting login scripts to run synchronously seems to be doing the trick after a lot of mucking around. However you should also check the event log on target computers in Microsoft-Windows-PrintService and if there are a lot of errors referring to malformed registry keys for specific printers then go into HKEY_CURRENT_USER \ Printers \ Connections and remove the subkeys for specific printers. In my test case deleting all these keys stopped the errors from appearing in the Event Log and allowed the printers being mapped in the login script to appear in the Printers folder.

The next step will be to have more printers being added in the login script. Just why this appears to be successful when GPP Printers does not work isn’t particularly clear. For us as system administrators a series of experiences where Windows 7 technologies appear to be lacking proper resourcing or support from Microsoft demands we respond with a “back to basics” approach and revert to tried-and-true, in this case logon scripting (which I thought had gone out with the ark). I don’t consider myself to be a programmer but that script will be getting updated and added to in future in order to make sure that printer installation and configuration can be relied upon. This is very important because incorrect printer installation will cause a lot of strange errors and problems with lots of everyday applications. I have seen these numerous event log errors before and deleting the keys from the Registry is not a new experience. I wrote about it here in fact. And looking back at that situation it is by remarkable coincidence (NOT!!!!) that the latest problems involve another Brother printer…

UPDATE: The saga continues because even though we have switched the server and clients over to driver isolation, the print spooler is still failing. The types of events now being logged are an inability to load the Brother print processor, even though it is not actually being used. In order to deal with this some registry keys that cause print processors to be loaded will need to be removed. I hope this fixes the problem as we have already paid for this printer and don’t want to have to return it. Here is the info about the registry keys:

The summary of this is to look for and remove registry keys under HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ Print \ Environments \ Windows NT x86 \ Print Processors. There will be subkeys named for each print processor in use in the system. The content is part of a much larger article on how to debug print spooler crashes. I hope this will be successful as the only other option is to get rid of the particular printer.

UPDATE 2: The above didn’t work in this case, as the registry keys didn’t exist. Although we are using x64, a search of the registry for the BrPrint processor failed to find its key, and there are no recent events for this print processor’s DLL failing to load. I can only assume with applying the isolation settings, the Brother print processors are not actually being loaded.

The solution now being tested is to do away with Brother drivers altogether. Most printers are compatible with HP drivers, and this printer turns out to work satisfactorily with the HP Universal Print Driver for PCL5. So far all testing is good. If it all turns out then all the Brother 64 bit print queues on our print server will be changed over to HP drivers.

V2P [4], Thin PC [4]

A couple of weeks ago I wrote about how our laptops which were set up with native boot VHD would all have to be V2Pd because VHDs on the native boot system tend to get corrupted more often. This week it is time to put that into reality by getting started on the 14 laptops which will be continuing over the next couple of weeks. The first step is to back up the VHD. Then we can mount it to a drive letter using Diskpart commands. We then use ImageX to capture it in place to a WIM. After ImageX is complete we apply the image to the same partition where the VHD was. We then remove the existing BCD from the boot partition (easiest just to format it) and then use bcdboot to create a new boot configuration on the system partition. Then we boot and the laptop should be exactly as it was.

The more experienced of you will probably say I left a step out, and I did. That’s because it shouldn’t have been necessary to sysprep the VHD because we were just moving the image from one partition to another. And because MS have limited the use of sysprep to a maximum number of times it can be done, I try to use sysprep a minimum amount. But regrettably sysprep has proven necessary in this instance, because Windows 7 will detect the subtle changes in the hardware environment and lock down the computer and say it is not genuine and there is absolutely nothing you can do to make it work normally. And with all of the negative comment I have written about MS in the past couple of weeks, I have to say that this adds further to that viewpoint, as does the rest of this post. I did get that computer working but it was a real mess to have to go through it all again after having sysprepped it and that should not have been necessary, it was totally unnecessary but that is another example of the MS mentality.

The second thing I have been working on lately is Thin PC, the latest effort being to see if it can run a very old software package we have which is called Successmaker 5.5. This package has been around our school pretty well for the last 6 years and we started with it on Windows 98. The installer that comes with it had some trouble on Windows 7 and it wasn’t totally due to lack of elevation, there were some of the things it was doing that just wouldn’t work at all for whatever reason. So I tried another tack. I built up a Windows XP machine and ran Ghost Autoinstaller (AI) on it to capture the machine state, I then installed SM on this machine, ran AI Snapshot again and built an AI installation. Then I went over to the Thin PC machine and ran this installation. I then had to customise some config files and then I tested it and it worked properly. So it looks like we can load up some machines with this version of 7 and have them running this old legacy package.

I then decided to capture the installation with sysprep and this is where I ran into problems. On reboot there was an error during installation, some problem with the product key, and Setup threw a fatal and told me to reboot. Well of course that did not fix the problem at all. This became another unrecoverable setup error like others I have seen before. The only fix is to remove the image and completely replace it. As you would understand this means I have to build the image again from scratch (as my pre sysprep image turned out to be corrupted). It’s becoming abundantly clear that Windows 7 Setup can’t actually recover from many errors and even if MS fixes the problems like this they have bought themselves another bad rep with OEMs and organisations which use imaging.

UPDATE: The one good thing about reimaging the laptop with a sysprep was that all I had to do after setup finished was join it to the domain. It picked up the existing user profiles and settings that were already on the laptop without problems. So it looks like to speed up this process, because I had to repeat nearly all the steps from the beginning to implement the sysprep, that we will just back up the VHD, then sysprep, then image etc. But sysprep would not have been necessary if some idiot at MS had not decided that we will make an image totally unusable instead of giving a user the chance to activate it again. And the same mentality exists when a setup fails and forces you to completely throw away your image and start again.