Samsung NP R522 screen replacement guide

I recently received a Samsung R522 from a customer that had a pretty beaten up screen.  Screen replacements are generally an easy fix, but I thought I’d post a quick run through here for anyone in doubt.

Step 1: Remove screw covers

Using a flat head screw driver, gently remove the screw covers dotted around the periphery of the screen there are 6 in total.

Screw Covers

Carefully remove screw covers

Step 2: Unscrew screen casing

Once you have removed the screw covers you can unscrew the the screws around the screen casing.  Remember to put them in a safe place like a glass or something as they are tiny and very easy to lose!

Step 3:  Gently separate the casing from screen

Using a credit card or something similar ( maybe something of less valus incase you snap your card ), very gently separate the case from the screen.  Do this by inserting the card in the gap between front and back of casing and easing around the entire casing hood.

Separate the case from the screen

Once you have worked your way around the case, gently separate the plastic lid from the screen and the back of the casing.

Ease the plastic lid from the screen and back of casing

Step 4: Unscrew screen from brackets

The screen is held in place by two brackets, one on either side of the screen.  It is attached by 3 screws on each bracket.  Locate and unscrew them.

Unscrew screen from brackets

Step 5:  Remove ribbon cable from back of screen

Now that you have access to the back of the screen, gently unstick the yellow tape holding the ribbon in place and then slide the ribbon connector down to release it from the screen.

Remove ribbon cable

Step 6: Out with the old, in with the new!

You can now safely remove the old screen and replace it with the new one.

Step 7:  Reattach the cable & attach to bracket

Simply do the reverse of the 2 last steps!

Step 8:  Screw in the plastic lid & boot up laptop

Screw the lid back onto the casing of the screen and cover the screw heads with the screw covers you removed in the first step.  Voila!  You’ve just replaced your screen!  Boot up and make sure that all is well.

It works!


Using MDT 2012 RC1 to deploy a VHD to a host machine

Over the past few weeks I have been playing around with MDT 2012 RC1, specifically the new Deploy to VHD feature.  Working in an educational institute, we have a need for VHDs for our students to practice using software that can’t be found on the regular desktop.  The ability to roll out a VHD to a host machine is very appealing and a welcomed addition to the MDT deployment toolkit.

I had a look through the documentation and saw that the new feature uses a new Task Sequence to deploy an OS to a VHD file and add it to the BCD Store so that you may boot into the VHD as you would any OS.

This wasn’t exactly what I was after.  I already have a fully working VHD that has all the software preloaded, I just want to roll out a VHD file to the host machine without it formatting the entire HD.  After some digging around on the Internet and a quick trip to the deployment forums over at Microsoft, I came to the conclusion that the Task Sequence was going to need some serious tweaking to get this to work.

So, what exactly am I trying to achieve here?

I need to deploy an OS and applications to a host machine, as well as copy across a fully working VHD and add it to the BCD Store.  Simple.


Before delving right into the walkthrough, let’s look at some important background information…

We are going to be calling a script from the deployment share called ZTIVHDCreate.wsf, found in the Scripts directory in the root of the share.  This script has lots of variables that we can use when calling the script, these are show in the below screenshot and listed underneath:

**VHDInputVariable [ Input ]  – Name of Variable containing the target for the VHD file.

**VHDOutputVariable [ Input ]  – Name of variable to receive New Disk Index (Typically OSDDiskIndex for ZTIDiskPart.wsf).

VHDDisks  [Output ]  – Partition Index

VHDCreateFileName (Optional) – Name of VHD File to create (“RANDOM” or “” to auto generate name)

VHDCreateDiffVHD (Optional) – Name of VHD Differencing Disk ( “RANDOM” to auto generate name)

VHDCreateSource (Optional)  – Name of VHD File source to prepopulate the new VHD

VHDCreateSizeMax (Optional)  – Maximum Size (in MB) of the VHD file (Default: 90% of parent disk)

VHDCreateType  (Optional)  – Creation Type of the VHD Disk Either FIXED or EXPANDABLE (Default: EXPANDABLE)

** Required.

This walkthrough assumes that you have a working knowledge of MDT.  It also assumes that you have a VHD already created and ready for deployment.

Step 1: Set up test environment

For a test environment, it was suggested by Johan Arwidmark – a prolific deployment guy, to use a Virtual Image and to take a snapshot before deploying the VHD.  This will allow you to restore the snapshot if the VHD deployment doesn’t go as planned.  I used Virtual Box to create a Windows 7 image which I then installed guest additions and sorted out the networking.  At this stage, take a snapshot.

Step 2: Store the VHD on the deployment share and map to the share

Seeing as you will be accessing the VHD during deployment, it seems logical to store it on the deployment share itself.  I chose to create a directory called VHDs and dump it in there.  Now that we have the VHD somewhere we can access it, we need to map a drive to the share from our test environment.  Do this from an elevated command prompt using the net use command as the scripts we run later require admin privileges:

Net use V: \\Name of server\Name of share

Eg.  Net use V: \\DeploymentServer\Deploymentshare$

Now that we have the VHD stored in a central location and have a drive mapped to that location, we are ready to run the script.

Step 3: Call deployment script

As mentioned at the top of this walkthrough, we will be calling the ZTIVHDCreate.wsf script to deploy the VHD.  This script is worth a read through so that you understand what it is you are about to run.  When calling the scripts, we can use variables to give additional details to the deployment.  Some of these variables are optional, but some are requirements.  Those that are required are denoted by a double asterisk at the top of the guide.  The basic, stripped down command looks like this:

Cscript.exe ZTIVHDCreate.wsf /VHDInputVariable:VHDTargetDisk /VHDOutputVariable:OSDDiskIndex /DeploymentType:NEWCOMPUTER

You’ll notice the additional parameter, DeploymentType.  This is a required parameter but for some reason has been omitted from the script documentation.  This is what the command looked for me when I came to call it:

cscript.exe “\\DeploymentServer\DeploymentShare$\Scripts\ZTIVHDCreate.wsf” /DeploymentType:NEWCOMPUTER /VHDInputVariable:VHDTargetDisk /VHDOutputVariable:OSDDiskIndex /VHDCreateSizeMax:51200 /VHDCreateFileName:Win7 /VHDCreateSource:”\\DeploymentServer\DeploymentShare$\VHDs\VHDTest.vhd”

So with the addition of some extra parameters, we can give it a maximum file size – note that this is only for expandable VHDs, and give it a name.

It takes some time for the VHD to copy across depending on how large the file is.  Remember that if you run into any problems or if your VHD didn’t deploy as cleanly as you had expected, you can always restore the snapshot from Virtual Box Manager.

Step 4: Deploying a host OS and a VHD

So far we have deployed a working VHD to a host machine by manually calling on the ZTIVHDCreate.wsf script.  Now that we have had some success with that, it’s time to run it from within a Task Sequence along side the deployment of a host OS.

To do this we will use a standard client deployment TS, rather than either of the client/server VHD deployments.

This deployment is exactly the same as a regular OS deployment but with the addition of the VHD after the installation of the applications.

So, to get this working, we’re going to add the command line we created in the last step and add it as a step in the TS.  Firstly, we need to add a new command line item to the TS.

In the above screenshot you can see that I have added several command line items to the TS.  The second command line to be run is the command that we have previously created.  The first command line is the net use command that we ran from our test environment to map to the deployment share.  Depending on how your host OS was deployed, you may not need to use this command as you the deployment process may have used an admin account to map to the deployment share.  However, it was necessary for me as the deployment process is not done using my network admin account.

As you see from the screenshot below, the net use command is exactly the same as it was in step 2, but this time I have instructed the TS that I want the command run with a specific user account.  This is an account that is specifically used during deployment and is not my own, for security purposes.

Once you have added these two command line items to the TS, you should be able to deploy a fully functional VHD to a host at the same time as deploying the host OS!  Just one, optional, step remains…adding the VHD to the BCD Store.

Step 5:  Automating addition of VHD to BCD Store

I can take no credit for the script that automates this process.  I have shamelessly borrowed it from Dan Stolts.  You can find the full script at his blog.  Basically, all you need to do here is store the script somewhere on the deployment share, either in the scripts folder or in the same directory as the VHD itself.

Once stored on the share, we can add the third and final command line item to the TS.  The syntax of this command is as follows:

Path of script > path of LOCALLY stored VHD  >  Name of VHD to appear in the Boot menu.


\\DeploymentServer\Deploymentshare$\VHDs\BCDEdit.bat C:\VHD\Win7.vhd Windows7

And that’s it!  Having followed these instructions, you should now have a dual boot machine that runs with a VHD that you already have kicking around.

This method may not be the most efficient and may be tweaked over the coming weeks as I continue to play around with it.  I welcome your comments if you think something has been glanced over or if you have a better way of achieving this.  It works for me and there currently isn’t any other guides for this on the net!  Good luck in your deployment!

This slideshow requires JavaScript.

Fixing the 0xc000021a BSOD and overcoming other adversities

The latest computer to come my way through DigIT is a Compaq Presario and never have I seen such a job like this one!

The computer was handed to me with the information that Windows XP crashed just after the XP load screen. My first action was to see for myself what this crash entailed and on the first boot I noticed a Blue Screen of Death. At this, I thought I would run the XP repair console and fix the MBR and boot sector, but while I was looking for an XP disk I found a Memtest disk and thought I’d chuck that in there to test the RAM while I continued tearing my study apart looking for the disk!

After finding the XP disk and returning to the PC I noticed that after 55% of the first pass, memtest had discovered 37632 errors! It was clear that RAM had something to do with this problem. I threw in some different RAM sticks but the BSOD was still showing up. I caught a glimpse of the error code this time; c000021a. A quick Google search was a little discouraging as the majority of forums were recommending nuking the machine and starting from scratch. I had my XP disk though, and was determined to fix this without formatting the HD.

The DVD Rom on the desktop had black tape over it so I assumed that it was broken, so I used the CD drive instead. It failed to boot from the XP CD; I’d later find out that my XP disk was knackered. No worries, I thought to myself, I’ll use my USB DVD drive…No joys there either. Unfortunately this PC is too old to recognise USB drives as a boot-able device. So I spent the next 25 minutes creating an XP boot-able USB pen drive. The PC of course didn’t recognise this either! Beginning to hit my head against a wall here, I decided that I would use a Live disk that had mini XP on it, but that idea didn’t last long as I remembered that all my live disks are on DVDs and the DVD drive is broken…

So, I settled on the idea of taking it into the office with me and temporarily swapping out the broken DVD Rom for a working replacement. This enabled me to boot from the XP disk long enough to discover that it was broken. Luckily, a work colleague had a working disk that I was able to use. Once booted into the XP disk I was able to run the MBR and boot sector repairs from the command line within the repair console, I also ran a chkdsk. Once that was complete I rebooted only to see the same BSOD error code before me.

My colleague had the good idea of copying the Windows folder across from the mini XP disk to the PC. Once we had done this, we were able to get into the system although many components were broken. It looked as if the RAM had been causing problems for a while, as the majority of the system files were either missing or corrupt. Cutting our loses we decided to rebuild the PC, by this time I had made a backup of the HD.

Once rebuilt and with some replacement RAM, the PC seemed to have a new lease of life! Yet another happy customer…

MDT 2012 RC1

I got my hands on the latest release of MDT 2012 a couple of weeks back and finally got stuck into it this last week. Our deployment server was already 2012 beta 2 after some difficulties with MDT 2010 and our latest batch of HPs, so it was a simple upgrade from beta to release candidate 1.

The new interface and menu items look and feel pretty slick, the additional content is welcomed also, a good start! I haven’t had much time to play around with all the new features but here is what I’ve learned so far…

Adding applications
Adding applications hasn’t changed any since the 2010 version, however creating software bundles has changed slightly. Instead of simply choosing from a list of already uploaded software packages one at a time, you can select multiple items via check box. Brilliant for those who want to create software bundles that will roll out 20-30 applications during the TS without interaction with a user. The only problem is that when you select an item, regardless of the order at which you select, the apps will appear in the dependency page in alphabetical order. A bit of a let down in my book, but so far, the only gripe I have about the update.

Deploying a VHD
Most of those in the IT world are familiar with Virtual Machines now. So the ability to deploy an entire OS to a VHD file is very enticing. The new TS can also add the VHD to the boot menu making it bootable at startup. We have a real need at my place of work to roll out a complete OS to a client machine in addition to a fully functional VHD. Although originally intended to allow admins to roll out OS builds to files, I am determined to get this working! I will no doubt be posting more on this topic in weeks to come as it’s something I’m quite excited about.

The Workbench has a new feature allowing you to monitor what is currently being rolled out to client workstations. Should be a very useful feature while rolling out builds to multiple workstations across the whole organisation.

That’s all I’ve come across so far. I’ll be sure to add more notes when I come across the various new features of the software. Verdict so far? It’s looking pretty sweet!