Myth uncovered...data from a failed Hard Drive...

OK. I have done this; most of your HD recovery companies have done this; why shouldn't you do this...

I am talking about using the freezer trick to get a dead harddrive to spin after the click of death.

I do own software to help recover dead HDs, but sometimes its not enough. There are always hard cases were the drive has been 'clicking a while but I didn't think it would die on me' cases, or, 'I spilled a beer on my table while surfing the web on my laptop',

The freezer trick is something I had success with in the early 90's. The trick is to do it the right way. Listen up, I have recovered approx. 30+% of the HDs that come to my without the disk spinning, thats right, about 3 outta 10.

If you have a static bag, us it. If not, a ziploc will do. Place the HD into the bag and seal with a rubberband the best you can. This will help to keep condinsation to a minimum.

Be very carefull not to leave the drive in the freezer too long. about 20 to 30 minutes should be the sweet spot. Take the drive out quickly, connect it up to your PC, and power on. If the drive does not come on the first time, try again. The most tries I ever had before throwing in the towel was 3 times.

You will be suprised at how much money you can save your friends and family by being the recovery point for all of there pics and resumes.

If your interested in the Recovery Software, check this out... http://www.runtime.org/
I've been using this for years.

x86 Print Drivers installed to Server 2008 x64 Server

Hi again. Over the past months, I have been challenged to create a remote server design. After many brainstorming activities with several IT groups, we sold the idea for Windows Server 2008 Ent. 64-bit. From DFS replication (which is awesome; good job Microsoft), to a local DHCP server, the design is going very well. Until the print server came into scope.

Server 2008 has some new really useful feature when pertaining to print services. The only fault is as follows:

Microsoft must think if your server is 64-bit, your clients will be. (lol; not a chance)

Now, we have several Xerox and HPs at each remote site. This is a great chance to pilot the new Xerox UPD (Universal Print Driver). This software claims it can be used for almost every print manufacturer (yeah right)

We obtained the latest x86 and x64 Xerox UPD drivers, launched the Print Console to install x64 and x86 drivers. Of coarse. the x64 installed flawlessly. The x86 on the other hand, asked for the x86 Windows Server 2008 media. I popped the disk in and pointed to the media, but was unable to locate the ntprint.inf. Great, now what??? I attempted to use the x86 media for Server 2003, and the install complained again.

After some trial and error, I came across a few docs that helped.

First, to locate the proper ntprint.inf, we had to pull the info from the install.wim from the Server x86 media, stage the drivers on the network, and try again. Wouldn't you know, it worked.

To accomplish this, you need to install Windows AIK. I used my laptop and the install went fine.

Click here to download from MS

Next, input your 2008 x86 media in and browse to \Sources folder. Copy the install.wim to your local drive. I copied it to C:\Temp

Create a folder to mount the image. I used C:\mountedimage

Next CMD and path to the Windows AIK directory were the imagex tool is located :

C:\Program Files\Windows AIK\tools\x86

Use x86 if you are mounting the x86 install.wim

Input the following command: imagex /mount C:\Temp\install.wim 1 C:\mountedimage

Press Enter. The image will mount to the folder. You can now read the install.wim in Explorer.

Browse the mountedimage folder to this location:

\Windows\System32\Driverstore\Filerepoitory\ntprint.inf_xxx

xxx is a custom hex value

Copy the contents to a network share for later use

Next, try to install the x86 driver again. When prompted, point to the location where you saved the ntprint.inf_xxx information.

The install should continue without error. Pain in the arse but doable.

I hope this helps others to apply the x86 drivers to the x64 server.

Scripting fun : Annoy your co-workers

I am a big fan of scripting (or any kind of automation for that matter. No matter what the task, there is almost always a reason to create a script and automate at least a piece of what you are trying to accomplish.

I will be honest, I am not script savvy enough to write complicated scripts. Thats what google.com is for.

I do have a script I would like to share. I can not take credit for writing it, I found if many years ago and just recently cracked it out to annoy a friend at work.

Great for April Fools!

vbscript to open a computer CD drive...


Const CDROM = 4
For Each d in CreateObject("Scripting.FileSystemObject").Drives
If d.DriveType = CDROM Then
Eject d.DriveLetter & ":\"
End If
Next
Sub Eject(CDROM)
Dim ssfDrives
ssfDrives = 17
CreateObject("Shell.Application")_
.Namespace(ssfDrives).ParseName(CDROM).InvokeVerb("E&ject")
End Sub

Print Server administration without Administrator access

OK. Lets say an client support person manages the shares printers at a remote site. The remote server is a standard file and print server, Windows Server 2003 SP2 (32 bit)

The client support staff has little (if any) rights to the server. If your admin model is written like ours, you need to grant access for the manipulation of Prints, Printer Ports, Print Driver Installations; without giving Administrative access to the server.

Here are the proper steps to accomplish this, without inheriting a security risk to your infrastructure:

Step 1: Create an Active Directory Group for Remote Server Print Admins

Step 2: Add said group to the following local groups on the server where the printers will reside

The admins can now RDP to the server, and manage current printers, change existing attributes

Step 3: Open secpol.msc (If you don't know how to get here, STOP Administering Servers!!!) LOL)

Add the said AD group to "Local Policy\User Rights Assignment\Load and Unload Device Drivers"

See pic above

Save and your done!

The admins can now create ports and add print drivers to the server.

NeopAdmin - Tech Advice

This is my first attempt at a blogging. I am a bit of a newb at bloggin, so bear with me.

I would like to start out by introducing myself. My name is PJ, I am a 35 yo IT professional working in the financially strapped city of Cleveland Ohio. I have worked in IT for almost 15 years and have moved from several different companies. Over the years, I have found (like most IT folks) many useful sites with tips for troubleshooting, automating, and designing technology solutions. I think its time for me to share my experiences and hope that someone will find it helpful.

My first posted tip:

My nemisis Citrix, administration nightmare (at least how we are using it). We upgraded the License server OS to R2 (Server 2003) for DFS R2 capabilities. As most of you know, R2 is a pretty straight forward install which does not require a reboot of the OS after installation. Typically I do a reboot for piece of mind, but was hesitant as this server has several roles. SQL Service 2K5 for Citrix, Sungard Paragon (for DR), SCCM Distribution point (on SAN Disk), are all currently running here. The upgrade completed without issue on Monday evening. Tuesday morning, everything still looked healthy. I setup the DFS R2 services for replication and shared namespace around 8 AM.

Around 11 AM the first IM came in from a remote admin in Quebec, Citrix Shadowing was not displaying users. Uh oh! Then, another IM from a Client Admin at corporate, the Access Manager Console would not connect.

I went straight to the source, the 3 Citrix servers in production with the console published. Upon trying the connection, nothing, the discovery process ran and ran, no error, no success. I bounced one server after finding an IMA issue in the event log (a common issue with CTX Presentation Server 4,5). Logged in and tried to connect; no dice. Then it was off to the license server. No errors concerning any connectivity to the farm, but give it a shot. Rebooted, and tested the AMC again. Sure enough, conncted without issue.

Lesson learned: No matter what the patch, service pack, hotfix; always reboot!