Installing 64 bit print drivers on a 32 bit Windows 2003 R2 print server
Our print server at work is running the 32 bit version of Windows 2003 R2. Most of our desktop clients are now running the 64 bit version of Vista or Windows 7.
Some of the printers on the server are using HP’s universal print driver and herein lies my issue. Apparently these universal drivers are crap (more on this at a later time). One particular printer (HP 4345 MFP) was giving me the most issues. Some days users can print fine and other days they have to delete the printer and re-add it to be able to print, otherwise, the printer just prints gibberish in the top left corner of each page. This probably doesn’t seem like a huge deal but it isn’t the way printing should work either. I was having to help users with this printer on a daily basis which gets old after a few days.
Today, I decided to fix the issue once and for all instead of re-applying the proverbial “band-aid” on a daily basis.
I easily found a PCL 6 driver on HP’s website for the 4345 MFP that supported both 64 bit and 32 bit XP/Vista. Next I was to add the print drivers to the server through the R2 print management console. The 32 bit driver was added without any issue but the 64 bit driver prompted me for the Windows 2003 server x64 CD, specifically, the AMD64 directory on the CD. Easy enough.
I put the 64 bit Windows 2003 Server installation disk in the server and browsed to the AMD64 directory like the print driver wizard asked but the server prompted again, this time "the specified location does not contain the driver HP LaserJet 4345 MFP Series PCL 6 for the requested processor architecture". After a few minutes of scratching my head and pointing the wizard to the AMD64 directory again and again I realized that, clearly, something was wrong.
It ends up that you have to install 64 bit print drivers from a machine of the same architecture (x64). I went to one of my 64 bit windows servers, installed the print management console through add/remove programs (thanks R2), connected to the 32 bit printer server, installed the 64 bit drivers and WALLAHH! the drivers installed on the server with no issue whatsoever.
I feel pretty silly now because I didn’t realize this issue sooner but I’m pretty new to supporting 64 bit windows clients machines so that’s my excuse. Hopefully, this will save another fellow sys admin from having their own “DUH!” moment.
If you are getting this error “Please install the build and header files for your current Linux kernel” when installing vboxadditions on a Fedora VM here is how you fix it:
yum install kernel-devel-2.6.29*
**You have to replace the above kernel build number with the one that the error spit out or it won’t work. Mine just happened to be 2.6.29**
We started moving a few people to Windows 7 this week and I discovered that none of the computers were getting the computer GPO settings applied. My company tends to keep domain computers in the default AD “Computers” container.
It appears that Windows 7 computers left in the default “Computers” container will not recieve the computer settings from any GPO’s that would otherwise be applied.
I haven’t been able to confirm this as a “by design” feature of the new OS but it is definitely the case for me.
Once I moved the Windows 7 computers into an appropriate OU and rebooted them computer settings were applied with no issue.
I guess Microsoft finally got around to actually enforcing one of their best practices.
Interesting.
I have been struggling with this one since I started running the Windows 7 RC. Now that Windows 7 has officially been released there is this workaround that worked for me. http://www.techhead.co.uk/running-vmware-vsphere-client-on-windows-7
On several occasions at work I have been asked to add email aliases to distribution groups for testing purposes. Depending on how many you have to add, in my case 30 or more, doing this through the exchange systems manager just won’t do. I mean, what self respecting systems engineer is going to copy and paste all these addresses one by one? Not me…did that the first time in a crunch and not doing it again.
Anyway, since there is a need for multiple email addresses we usually identify each by using a basic format followed by a number increment (user1, user2, user3 and so on and so forth). Since the aliases all have the same email address prefix I figured this was ripe for some powershell scripting so without further ado here is what I came up with.
#gets the distribution group name and puts it in a variable
$group = get-distributiongroup “example_group“
#enter starting number here
$i = 1
#enter email prefix
$user = “user“
#email domain address
$addr = “@yourdomain.com“
#This is the loop. It will continue adding addresses until the ending number is reached.
do {
$newaddr = $user+$i+$addr
$group.emailaddresses += $newaddr
set-distributiongroup -Identity $group -EmailAddresses $group.emailaddresses
$i +=1
}
#enter ending number in place of “40″
while ($i -le 40)
The above example will create email aliases for the distribution group called “example_group” starting with “user1@yourdomain.com” and ending with “user40@yourdomain.com”. If you wanted to increment another number just change the starting and ending numbers in the script.
This is the output from “robocopy /? > robocopyswitches.txt” run from a Windows 7 command prompt.
——————————————————————————-
ROBOCOPY :: Robust File Copy for Windows
——————————————————————————-
Started : Tue Sep 01 08:55:42 2009
Usage :: ROBOCOPY source destination [file [file]…] [options]
source :: Source Directory (drive:\path or \\server\share\path).
destination :: Destination Dir (drive:\path or \\server\share\path).
file :: File(s) to copy (names/wildcards: default is “*.*”).
::
:: Copy options :
::
/S :: copy Subdirectories, but not empty ones.
/E :: copy subdirectories, including Empty ones.
/LEV:n :: only copy the top n LEVels of the source directory tree.
/Z :: copy files in restartable mode.
/B :: copy files in Backup mode.
/ZB :: use restartable mode; if access denied use Backup mode.
/EFSRAW :: copy all encrypted files in EFS RAW mode.
/COPY:copyflag[s] :: what to COPY for files (default is /COPY:DAT).
(copyflags : D=Data, A=Attributes, T=Timestamps).
(S=Security=NTFS ACLs, O=Owner info, U=aUditing info).
/DCOPY:T :: COPY Directory Timestamps.
/SEC :: copy files with SECurity (equivalent to /COPY:DATS).
/COPYALL :: COPY ALL file info (equivalent to /COPY:DATSOU).
/NOCOPY :: COPY NO file info (useful with /PURGE).
/SECFIX :: FIX file SECurity on all files, even skipped files.
/TIMFIX :: FIX file TIMes on all files, even skipped files.
/PURGE :: delete dest files/dirs that no longer exist in source.
/MIR :: MIRror a directory tree (equivalent to /E plus /PURGE).
/MOV :: MOVe files (delete from source after copying).
/MOVE :: MOVE files AND dirs (delete from source after copying).
/A+:[RASHCNET] :: add the given Attributes to copied files.
/A-:[RASHCNET] :: remove the given Attributes from copied files.
/CREATE :: CREATE directory tree and zero-length files only.
/FAT :: create destination files using 8.3 FAT file names only.
/256 :: turn off very long path (> 256 characters) support.
/MON:n :: MONitor source; run again when more than n changes seen.
/MOT:m :: MOnitor source; run again in m minutes Time, if changed.
/RH:hhmm-hhmm :: Run Hours – times when new copies may be started.
/PF :: check run hours on a Per File (not per pass) basis.
/IPG:n :: Inter-Packet Gap (ms), to free bandwidth on slow lines.
/SL :: copy symbolic links versus the target.
/MT[:n] :: Do multi-threaded copies with n threads (default 8).
n must be at least 1 and not greater than 128.
This option is incompatible with the /IPG and /EFSRAW options.
Redirect output using /LOG option for better performance.
::
:: File Selection Options :
::
/A :: copy only files with the Archive attribute set.
/M :: copy only files with the Archive attribute and reset it.
/IA:[RASHCNETO] :: Include only files with any of the given Attributes set.
/XA:[RASHCNETO] :: eXclude files with any of the given Attributes set.
/XF file [file]… :: eXclude Files matching given names/paths/wildcards.
/XD dirs [dirs]… :: eXclude Directories matching given names/paths.
/XC :: eXclude Changed files.
/XN :: eXclude Newer files.
/XO :: eXclude Older files.
/XX :: eXclude eXtra files and directories.
/XL :: eXclude Lonely files and directories.
/IS :: Include Same files.
/IT :: Include Tweaked files.
/MAX:n :: MAXimum file size – exclude files bigger than n bytes.
/MIN:n :: MINimum file size – exclude files smaller than n bytes.
/MAXAGE:n :: MAXimum file AGE – exclude files older than n days/date.
/MINAGE:n :: MINimum file AGE – exclude files newer than n days/date.
/MAXLAD:n :: MAXimum Last Access Date – exclude files unused since n.
/MINLAD:n :: MINimum Last Access Date – exclude files used since n.
(If n < 1900 then n = n days, else n = YYYYMMDD date).
/XJ :: eXclude Junction points. (normally included by default).
/FFT :: assume FAT File Times (2-second granularity).
/DST :: compensate for one-hour DST time differences.
/XJD :: eXclude Junction points for Directories.
/XJF :: eXclude Junction points for Files.
::
:: Retry Options :
::
/R:n :: number of Retries on failed copies: default 1 million.
/W:n :: Wait time between retries: default is 30 seconds.
/REG :: Save /R:n and /W:n in the Registry as default settings.
/TBD :: wait for sharenames To Be Defined (retry error 67).
::
:: Logging Options :
::
/L :: List only – don’t copy, timestamp or delete any files.
/X :: report all eXtra files, not just those selected.
/V :: produce Verbose output, showing skipped files.
/TS :: include source file Time Stamps in the output.
/FP :: include Full Pathname of files in the output.
/BYTES :: Print sizes as bytes.
/NS :: No Size – don’t log file sizes.
/NC :: No Class – don’t log file classes.
/NFL :: No File List – don’t log file names.
/NDL :: No Directory List – don’t log directory names.
/NP :: No Progress – don’t display percentage copied.
/ETA :: show Estimated Time of Arrival of copied files.
/LOG:file :: output status to LOG file (overwrite existing log).
/LOG+:file :: output status to LOG file (append to existing log).
/UNILOG:file :: output status to LOG file as UNICODE (overwrite existing log).
/UNILOG+:file :: output status to LOG file as UNICODE (append to existing log).
/TEE :: output to console window, as well as the log file.
/NJH :: No Job Header.
/NJS :: No Job Summary.
/UNICODE :: output status as UNICODE.
::
:: Job Options :
::
/JOB:jobname :: take parameters from the named JOB file.
/SAVE:jobname :: SAVE parameters to the named job file
/QUIT :: QUIT after processing command line (to view parameters).
/NOSD :: NO Source Directory is specified.
/NODD :: NO Destination Directory is specified.
/IF :: Include the following Files.
Works like a charm.
http://seer.entsupport.symantec.com/docs/287063.htm
Hello everyone,
We finally upgraded our print servers to SP2 and had a problem. I banged my head with it for about one hour and thought it would be worth reporting the solution since it’s a potential problem for others:
Symptomes: Some network printers published by a Windows 2003 SP2 server will be marked as “offline” and cease to be available. Restarting the spooler will make the printers briefly available (for 30 seconds or so) before they reset to offline status.
Problem: MS has changed the way SNMP-enabled printer are handeled in SP2. I don’t have the full detail, but apparently any printer that is marked as SNMP enabled (by the driver, I assume) will REQUIRE (by default) SNMP to be setup correctly and working on both the printer and local server (community names). Never mind if these printer all have SNMP actually disabled.
Solution: On the properties of each printer (on the server), select the “port” tab, local the correct port, click on “configure” and uncheck “SNMP enabled”. Once you click “ok” the printer’s status will be instantly turned back to normal.
Edit: I forgot to give credit to the place I actually found the solution: http://www.hoyty.com/hoytyweblog/archives/2007/04/windows_2003_se.html
Recently after installing systems center essentials 2007 and pushing the agent to our exchange servers I started getting an alert that the “Internal transport certificate has expired” This certificate is crucial to the communications and transport of mail from/to the edge and hub transport servers, without it you stop recieving email.
Thanks to SCE I was able to be somewhat pro-active and fix the issue before anyone at my company noticed any real downtime. The alert allowed me to pinpoint the issue without having to do a lot of troubleshooting and get on with the fix.
Unfortunately, I found the documentation on Microsoft’s technet site a little lacking. It wasn’t that the directions were wrong just that I feel there were a few steps left out in fixing this issue properly. In all fairness it could have been that I overlooked a step our two researching the exact order I was to perform the steps.
After finally getting the issue resolved I decided to actually document what I did, in order, so that my frustrations would not be experienced again and I could share with everyone else.
From your edge server:
In Exchange Powershell perform the following commands:
New-exchangecertificate
Remove-edgesubscription
New-edgesubscription –FileName “c:\whatever.xml”
Copy the xml file just created to your Hub Transport server.
From your Hub Transport server:
Open Exchange Management Console and go to ”Organization Configuration > Hub Transport > Edge Subscription”
Remove the current edge subscription
Click New Edge Subscription (right hand task menu)
Import the xml file you copied.
From your edge server:
Restart Microsoft Exchange ADAM service
From your hub transport server:
Open the exchange powershell and perform the following commands:
start-edgesynchronization
Now your exchange edge subscription should be unsubscribed/resubscribed with a newly created internal transport certificate and mail should start flowing as usual.
I have really been trying hard to use a MacBook Pro (Intel) as my primary laptop at work. Being a network engineer in an all Windows environment has made this transition a very frustrating one to say the least. My main source of frustration has been performance, or lack thereof, of the Windows virtual machines running in Fusion. The MacBook Pro I have been using only has 2 GB of RAM and supposedly only goes up to 3 GB (I am still researching this). Needless to say, this was a huge part of the problem in successfully running the Windows VM’s in the background.
On Monday of this week I bought a 2 GB stick of RAM on sale from Microcenter for $30 to bump the memory on the Mac up to its proverbial ceiling of 3 GB. This has made all the difference so far. I am now able to run Windows Vista with a full 1GB of memory and OSX still has 2 GB all to its self. In addition, I found this post http://blogs.vmware.com/teamfusion/2008/09/optimizing-vist.html which gave me some nice tweaks to the Vista VM and now the whole system is running even better than with just the memory upgrade. It still isn’t as fast as I would like it to be or as fast as my Thinkpad T60p running Vista but I am definitely not giving up the ghost just yet.
If I can just disparage the rumors that my MacBook Pro doesn’t go past the 3 GB of memory claimed I might just be a convert after all.
