You need chaos in your soul to give birth to a dancing star. – Friedrich Nietzsche
I.T.
Information Technology related posts
Windows 7 Printers & 0x8007007E (The specified module could not be found) …
So here’s the scenario:
(1) A Windows Server 2003 (x86) print server
(2) A bunch of HP printers using HP’s universal driver — specifically, the PCL5 driver. All printers are connected to the aforementioned server via the network.
(3) A bunch of Windows 7 Pro x64 clients with the aforementioned PCL5 driver installed.
Problem:
Printers (on x64 clients) won’t map — the client machines can’t connect to the HP printers on the server. You may get various error messages/symptoms; I discovered this problem when a domain login script wouldn’t map printers. Here’s a simplified example of what the script might look like:
Set objNetwork = CreateObject(‘WScript.Network’)
objNetwork.AddWindowsPrinterConnection ‘\\server\\printer’
objNetwork.AddWindowsPrinterConnection ‘\\server\\printer’
Whenever the domain login script ran, the following error would appear:
The error message reads:
Error: The specified module could not be found.
Code: 8007007E
Source: (null)
Code: 8007007E
Source: (null)
You may also get an error with the following code:
Error: Cannot connect to printer
Code: 0000007E
Code: 0000007E
What causes this?
When the 32 bit universal driver is installed on the server, a registry key is created:
HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers\<printer name>\CopyFiles\BIDI
This key exists to tell the client that it needs to copy a dll file to in order for the printer to work on the client machine. The problem is that the path points to the 32 bit version of the driver (which makes sense, because the print server is a 32 bit machine). The 64 bit clients need the 64 bit version of the driver — which you’ve already installed on the client machines (you did install it… right?) Whenever the 64 bit client tries to load this 32 bit module, the above error(s) is(/are) the result; additionally, you’ll see the following error in the Event Viewer:
As it turns out, this is a very easy problem to fix; just delete the BIDI key. The client machines will no longer be told that they need to copy the wrong file and they’ll connect just fine. But what about 32 bit clients? Well I haven’t noticed any ill-effects from deleting the key but I’d imagine that the worst that can happen is that you might have to install the PCL 5 driver on the 32 bit clients rather than having the server do it whenever a client attempts to connect to a shared printer. As I said though, I haven’t noticed any problems yet and 32 bit machines are on their way out anyway. Hopefully this post saves someone else some time.
Further Reading:
http://www.lewisroberts.com/2011/09/08/windows-cannot-connect-to-the-printer-0x0000007e/
Opening Terminal Server registry propogation window. (aka: Installing software in windows takes forever)
That’s not a typo. For the past few months, I’ve noticed that installing software or running updates on one particular terminal server that I manage (Windows Server 2003, std.), the updates/installation take hours — in some cases, days. So I enabled windows installer logging and here’s what I found:
MSI (s) (2C:30) [01:58:16:558]: Opening Terminal Server registry propogation window.
MSI (s) (2C:E8) [02:35:44:188]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:13:14:358]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:50:44:453]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [04:28:14:529]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:05:44:619]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:43:14:897]: RunEngine wait timed out
Installer is no longer responding.
Action ended 5:52:07: InstallInitialize. Return value 1.
MSI (s) (2C:30) [05:52:07:859]: Doing action: SxsInstallCA
Action start 5:52:07: SxsInstallCA.
MSI (s) (2C:E8) [02:35:44:188]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:13:14:358]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [03:50:44:453]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [04:28:14:529]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:05:44:619]: RunEngine wait timed out
Installer is no longer responding.
MSI (s) (2C:E8) [05:43:14:897]: RunEngine wait timed out
Installer is no longer responding.
Action ended 5:52:07: InstallInitialize. Return value 1.
MSI (s) (2C:30) [05:52:07:859]: Doing action: SxsInstallCA
Action start 5:52:07: SxsInstallCA.
So as you can see by the snippet above, this routine installation took an enormous amount of time. This exact scenario played out anytime I tried running updates or installing software. As it turns out, this was the problem. Simply removing the driver and deleting the following registry keys, and then installing the latest version of the driver (… I was on ~3 something; at the time of this writing, the latest version is 6.1) fixed the problem. Here are the registry keys that should be removed after the driver has been uninstalled (and before the latest version has been installed):
HKEY_LOCAL_MACHINE\SOFTWARE\Hewlett-Packard
HKEY_CURRENT_USER\SOFTWARE\Hewlett-Packard
HKEY_USERS\.DEFAULT\Software\Hewlett-Packard
HKEY_CURRENT_USER\SOFTWARE\Hewlett-Packard
HKEY_USERS\.DEFAULT\Software\Hewlett-Packard
This was an extremely frustrating issue — other symptoms included server crashes with an error message about the registry being too large; logging in a brand new user for the first time takes ~15 minutes or so, and a whole host of other performance related weirdness. At first I thought that installing UPHClean would help solve this (the symptoms being registry-related and all) but it may have actually made the problem worse. If you scroll all the way down to the bottom of the page of the previous link to HP’s website, you’ll see the following post:
JulianBlue Oct 6, 2010 07:37:53 GMT
It is very likely that HP UPD problem replicating tons of registry keys to global default registry hive (.DEFAULT) being related to Terminal Server on which the Microsoft UPHClean Tool is installed. I would recommend to look at the readme.txt with UPHClean and setup an exclusion for svchost.exe/rpcss.dll.
It is very likely that HP UPD problem replicating tons of registry keys to global default registry hive (.DEFAULT) being related to Terminal Server on which the Microsoft UPHClean Tool is installed. I would recommend to look at the readme.txt with UPHClean and setup an exclusion for svchost.exe/rpcss.dll.
“UPHClean assists the operating system to unload user profile hive by remapping the handles to the user profile hive to the default user hive. For example if a process has a handle to HKEY_USERS\S-1-5-21-X-Y-Z\Software\Microsoft after remapping it would have a handle to HKEY_USERS\.DEFAULT\Software\Microsoft.”
I haven’t had the chance to test this yet, but it does sound plausible enough. There’s also some other posts related to this on HP’s website that are worth having a look at. Here’s the readme.txt that comes with UPHClean. Setting up an exclusion list is fairly straightforward; for convenience, I’ve pasted the pertinent section of the UPHClean readme here:
PROBLEMS USING UPHCLEAN
=======================
=======================
Because UPHClean assists in unloading the users registry
hive some services may behave incorrectly. Administrators
are encouraged to test and watch for unexpected behavior.
If unwanted behavior is identified contact the developers of
software that UPHClean identified as preventing profile from
unloading.
UPHClean assists the operating system to unload user profile
hive by remapping the handles to the user profile hive to the
default user hive. For example if a process has a handle to
HKEY_USERS\S-1-5-21-X-Y-Z\Software\Microsoft after remapping
it would have a handle to HKEY_USERS\.DEFAULT\Software\Microsoft.
This allows the profile hive to unload. This may not work if the
application expects data that would only be available under the
specific user profile hive it was accessing since the data will not be copied.
If you find that removing UPHClean stops a particular problem from
occurring then you may be interested in restricting UPHClean from
processing certain handles. UPHClean ignores handles that are
held opened to profile hives for the users specified on the user
exclusion list or by processes specified on the process exclusion list.
These lists are specified using the following registry values:
HKLM\System\CurrentControlSet\Services\UPHClean\Parameters\PROCESS_EXCLUSION_LIST
HKLM\System\CurrentControlSet\Services\UPHClean\Parameters\USER_EXCLUSION_LIST
Note that since these values are specified as REG_MULTI_SZ strings
you should use regedt32 on Windows NT and Windows 2000 to edit them.
The process exclusion list is a list of process names that UPHClean
should ignore when determining which handles to user profile hives
to act on. Each process name is specified on its own line when
input in registry editor. The process name should be specified the
same way as it shows in Task Manager. Usually this is the file
name of the program (e.g. notepad.exe).
A few process show multiple times in Task Manager. It is possible to
specify that a certain DLL be loaded in the process to allow a selection
of a specific process. This is useful with the svchost process to identify
a specific instance. For example to specify the svchost process that
the Remote Procedure Call (RPC) service is running in on Windows 2000,
Windows XP and Windows Server 2003 you would specify
svchost.exe/rpcss.dll in the process exclusion list
The user exclusion list is a list of user security identifier (SID) or user that
UPHClean should ignore when determining which handle to user profile
hives to act on. Each user SID or name is specified on its own line when
input in registry editor. If specifying a user name you must enter the user
domain name followed by a backslash followed by the user name. For
example RCARONDOM\RCARON to specify the user RCARON from
domain RCARONDOM. SIDs should be specified in the usual string
format (e.g. S-1-5-21-2127521184-1604012920-1887927527-68486).
This is the same string you see under HKEY_USERS in registry editor.
Note that the user exclusion list always includes the following
SIDs: S-1-5-18, S-1-5-19, S-1-5-20. Unloading these profiles can cause
problems so UPHClean will not attempt to process handles to these profiles.
Which processes UPHClean performs handle remapping can specified
using the following registry value:
HKLM\System\CurrentControlSet\Services\UPHClean\Parameters\REMAP_HANDLE_PROCESS_LIST
The list by default contains ‘*’ which specifies that handle remapping should
be performed for all non-excluded processes. This list can be changed to
only include specified processes in the same manner as the process
exclusion list. Processes specified on this list can be preceeded by a ‘-’
character to specify that they should be excluded from handle remapping.
Any handle for a process that is not excluded but has handle remapping
turned off will be closed.
I hope this helps!
Solution for: “Microsoft office has stopped working” (applies to Office 2007 & 2010)
Symptoms: Microsoft word/excel/powerpoint/etc. crash a few seconds after being opened with the error message:
“Microsoft office has stopped working”
As a few clients of mine have upgraded to MS Office 2010, this problem has appeared a few times and it seems damn near impossible to fix… but there is a fix. You ready?
Set your default printer to the “Microsoft XPS Document Writer”.
I don’t know why this works, but it’s going to have to do until M$ releases and update/patch/fix/etc.
jqueryFileTree connector script for python cgi
If you use jquery and haven’t messed with the jqueryFileTree plugin, I’d highly recommend you do so. It’s pretty neat, and there are connector scripts already written in various languages for use with this plugin. However, there wasn’t one for python cgi (there was one for django however). So, I wrote my own! Try it out:
#!/usr/bin/python
# jqueryFileTree connector script for python cgi
# Version: 1.0 / 10 August 2010
# Author: Charles Hamilton / musashi@nefaria.com
# Released under the GNU GPLv3
# Modifications and improvements are welcome
import os, cgi, cgitb, urllib, re
cgitb.enable()
form = cgi.FieldStorage()
print ’Content-Type: text/html\n\n‘
print ’<ul class="jqueryFileTree" style="display: none;">‘
path = urllib.unquote(form['dir'].value)
dirs = []
files = []
filelist = sorted(os.listdir(path))
for object in filelist:
if os.path.isfile(path + ‘/‘ + object):
ext = os.path.splitext(object)
files.append(‘<li class="file ext_‘ + re.sub(‘\.‘, ”, ext[1]) + ‘"><a href="#" rel="‘+ path + object + ‘">‘+ object + ‘</a></li>‘)
elif os.path.isdir(path + ‘/‘ + object):
dirs.append(‘<li class="directory collapsed"><a href="#" rel="‘+ path + object +’/">‘ + object + ‘</a></li>‘)
for d in dirs:
print d
for f in files:
print f
print ’</ul>‘
