Showing posts with label build. Show all posts
Showing posts with label build. Show all posts

Sunday, 14 June 2015

1998 - 1999 Retro PC Build - When Nostalgia Gets The Better of Me.

I've always enjoyed building my own machines, it's not something I get to do much these days as I don't buy anywhere near as much new equipment as I used to. For anyone that knows me, gaming is a bit of a hobby that got out of hand when I was a young singleton with too much time on my hands. A collection habit started slowly, I started buying a lot of older games and consoles that I either owned as a kid, wanted as a kid or just wanted to try. Before I knew it I was sitting with a room full of old games and consoles, most of which in all honesty I'll probably never play. Collecting consoles is easy, you buy a console and some games and as long as you look after them they'll always play in the same way as you remember them.

PC gaming has always been a bit different for me though, with the PC there was always a "next big game" coming along that would require new hardware to run at maximum settings. This resulted in far too many upgrades over the years, sometimes it would be a simple upgrade of a graphics card, other times it would be full motherboard, CPU, memory, power supply etc, sometimes issues were software created in that a newer operating system had lost certain features that the older game required. The problem with this is that when you upgrade specifically for the purpose of playing a newer generation of games, you immediately lose compatibility with the previous generations. It's only now looking back that I can see so many games I used to love playing sitting in boxes in my attic that I will never play again, simply because I no longer have the hardware required to play them. Something must be done about this situation!

I still have a lot of older spare PC parts kicking around doing nothing in my garage, but no complete systems. My idea is to build a new "old" PC capable of playing these older titles using these bits and what I can find on eBay or in the wild. I'll aim to keep the internals of the systems to a specific time-frame, but won't limit myself to newer cases, fans, heatsinks or any part that may reduce negative factors of using parts of this era (such as heat, noise and energy efficiency) that have no performance or compatibility impact. The aim is not to build the "ultimate" machine from a specific time-frame, just a spec that would be broadly compatible with the games I played back in that time-frame. The idea ready, now all I need to decide is where to begin.

Specing and Part Selection

The earliest "good" PC I owned and actually played games on was back in 1994, a laptop computer with a 486DX2 66mhz CPU and monochrome screen. This was pretty much used to play old DOS games back in the day such Monkey Island and Civilization. I don't think I want to start there. Fast forward to 1998 is when I ordered parts for my first (then considered mid-range) "Custom PC". Here's the original spec.

AMD K62 350 Mhz
First International Computers VA503+  Super Socket 7 Motherboard (AT)
128MB PC 100
Jetway Wonder 4000 (S3 Savage 3D 8MB)
Skywell Magic 3D II (3DFX Voodoo 2 12MB)
Creative Soundblaster AWE64
Iomega Zipdrive
Floppy
Creative 36X CD-ROM
6.5GB Seagate HDD
Generic Whitebox AT Minitower
15" Generic Monitor
Generic 3 button comm port mouse
Generic AT keyboard

A build covering the 1998-1999 "era" would be a great place to start. At the time this great little PC opened up a whole new world of PC games for me and introduced me to hardware 3D acceleration. I remember great titles I instantly fell in love with such as Unreal, Unreal Tournament, HalfLife, Kingpin, Ultima Online, Civilization 2, Blade Runner, Red Alert 2 and many, many more that I've probably forgotten about that I'm soon to re-discover. This system also introduced me to the world of online-gaming for the first time. Utilizing the speed of a Diamond V.90 56K modem the first online game I ever played was Unreal - it was literally Unreal at the time; unlike anything I had experienced from anything I ever played previously. I also got heavily into Ultima online and at the time it was responsible for me receiving a £400 phone bill!

I don't have much left of this PC, so I decided to scout around for parts. I was lucky enough to find a Pentium 2 (SLOT A) 400Mhz and 256MB PC 100 in the electronic waste disposal bin at work, so I salvaged those. 

I'm trying to be sensible here, while money isn't an issue I don't want to spend a fortune on this build! I went to eBay and looked at AT boards, but I couldn't bring myself to limit myself to AT cases, comm port mouses and 5-pin din keyboards (I know converters exist but it's just something else I would have to buy). I then settled on an ATX board. I picked up a Gigabyte GA-6BXE motherboard for £6 - It also came with an additional 256MB RAM and a Pentium 3 650Mhz. I'm going to initially go with the Pentium 2 as it's closer to my original 1998 spec and I seem to remember that the fastest CPU at that time was the Pentium 2 450Mhz. Being SLOT 1 makes it incredibly easy to swap out the CPU in the event a later games requires a little bit more ooomph! 

I've found a 40GB  5400 RPM Western Digital IDE hard disk, a IDE DVD RW,  a floppy disk drive ,a Soundblaster Live 5.1 and an old Enermax 350watt PSU in my garage. As I will be installing most games from their original CD-ROM based media a good CD/DVD drive is a very important component. My Creative drive from back in the day sounded like a vacuum cleaner, so the opportunity to swap that out for a newer-gen (quieter) drive is crucial. Perhaps the most import piece of this build I still owned - my 3DFX Voodoo 2, never been able to let it go it seems. The oldest AGP card I could find in my garage was a Geforce 4 440MX 64MB - far too late for this build so again I took to eBay. 

Now, I remember back in the day being really frustrated with my S3 Savage 3D card - reading about it now confirms what I originally figured, it was a good card, crippled by poor drivers. I searched for a Savage 3D but couldn't find one on eBay at all - that says a lot about this card, I think everyone who had one probably binned it! I did find a S3 Savage 4 8MB and bought that. I remember when Unreal Tournament was released back in 1999 that the game came with S3 compressed textures specifically for that card. I tried this back in the day and it looked great, it was just a shame the card wasn't powerful enough to retain a playable framerate with these compressed textures turned on! As I planned to experiment with this and the hardware was dirt cheap (talking £4-7 per card) I also bought a (brand new) S3 Savage 4 16MB, a 3DFX Voodoo 3 3000 and an Elsa Erazor 3 (Nvidia TNT 2 32MB).  It would later be interesting to find out which of these I'd settle on for this build.

Now I've got most of the bits, I needed something to put it all inside. I settled on the CoolerMaster K380  at £23.99 from eBuyer.com - design wise it's not everyone's cup of tea, but I always liked CoolerMaster cases, this was the right pricepoint, it looks good, has 2x 3.5 external drive bays and has good cooling features. The case has support for 2X 120MM fans, which will be a great improvement over any older case I could find (my original machine back in the day had a 60MM delta "screamer" as an exhaust fan). 

The Build Process

The actual build itself was a straight forward process, the only things that slowed me down were the lack of manual for my motherboard (which I later found) and figuring out the CPU jumper settings was a bit of a throwback, I made sure to flash the system board BIOS with the latest binary available to try and avoid any compatibility issues. The CoolerMaster K380 case was a pleasure to work inside, no sharp edges and good layout, it provided ample space for all components. I was expecting there to be issues when using a bottom-mounted PSU - but none were experienced. Eventually I'll swap out the power supply with a newer more efficient model when time/money allows.

I fitted rounded IDE ribbon cables and used a few cable ties to hold the power supply cables away from the case window area, this immediately improved the look inside the case, but initially I wasn't so worried about cable management. 

The Final Spec is:

Pentium 2 MMX 400Mhz CPU (SLOT1)
Gigabyte GA-6BXE Motherboard
512MB PC100 (4X 128MB)
S3 Savage 4 16MB
3D FX Voodoo 2 12MB 
Creative Soundblaster 5.1
40GB Western Digital IDE HDD
Intel GT 1000 Network Card
4 Port USB 2.0 Card with 1x Internal Header (to connect to front panel)
Liteon DVD RW Drive
Floppy Disk
Enermax 350 Watt Power Supply
Coolermaster K380


The Case all sealed up and ready to go.

Inside the belly of the beast - still a bit of work to do with those cables!

Power on and lights on


Operating System Choice

Originally I had planned to install Windows 95 OSR2.1 on this machine, the sole reason for this was that I had the original media. It was a strange thing that when I ordered the parts for my original machine back in 1998 the store assistant advised me strongly not to use Windows 98 with a K6/2 Processor. He informed me of the Windows 95 and 98 both had problems with AMD processor faster than 350Mhz - this would turn out to be true for Windows95 where a patch was available to address this issue, but he also advised me at the time that Windows98 also had the same issue, but a patch was not at the time available for it. As I didn't have any Internet access at the time I couldn't confirm either way, I purchased the Windows 95 OSR 2.1 CD. Looking back now, he probably just had a load of old Windows 95 copies he was trying to get rid of!

I installed Windows 95 on the machine without any issues, having already created a bootdisc the lack of bootable CD media wasn't an issue to me, but once everything was installed I soon found it very painful when adding/removing new hardware. Every time having to "Insert the Windows 95 CD" for every action proved to be a real pain. Windows 98 is similar in this way, but it at least loads some of the most general, generic drivers onto the hard disk during the installation process. After a frustrating afternoon of this I was bored and I realized there was no advantage of compatibility between the two operating systems, the only factor drawing me to Windows 95 in the first place was out of nostalgia. I decided to switch to Windows 98 SE.

Following installation I had a bit of a job to track down all the various drivers required. It's amazing how many manufacturer's won't supply legacy drivers for their own products! It was a somewhat painful experience to locate them, but I think I'm running the latest drivers for everything.


Windows 98SE Install and ready to run

Installing Games

So far I've installed and played the following games without any issues. In most cases I've patched the games to the latest released version. 

Full Throttle (DOS)
The Dig (DOS)
Monkey Island (DOS)
Quake + GL Quake
Malice Quake addon
Quake 2 
Star Wars Jedi Knight
Westwood's Blade Runner
Star Trek Klingon Honour Guard
Star Wars Rogue Squadron 3D
Star Trek Armada
Resident Evil 
Kingpin
MechWarrior 2
Blood 2
MDK + 3DFX Patch
Turok the Dinosaur Hunter 2
Unreal
Unreal Tournament
System Shock 2
Syndicate Wars (DOS)
Theme Hospital (DOS)
Hexen 2
Warcraft 2
Starcraft 
Soldier of Fortune
Panzer Dragoon
G-Police
Severence
Populous - The Beginning
BattleZone 2 : Combat Commander
Dungeon Keeper 2
Hitman Codename 47
Command and Conquer : Red Alert
Quake 3 Arena
Dune 2000
Freespace
Rune
Star Wars: Xwing Alliance
Star Trek New Worlds
Star Wars : Shadows of the Empire
Return to Castle Wolfenstein
Civilization 2
Alpha Centari + Expansion
Sega Rally
Crimson Skies
Virtua Fighter PC
Sonic R
Sudden Strike

That's a fair amount of games installed


Performance for the most part is very good on the games tested. It's true most people would question why I've opted for the Savage 4 in favour of the TNT2, although the TNT 2 provides superior D3D performance, I actually found the Direct 3D Savage performance to be quite good, as with the TNT2 the card supports 32-bit colour and image quality is also very good,  it's actually far superior to the quality of Voodoo 2.  S3's Metal API also can be used in various Unreal engine games like Rune, Undying, Unreal and Unreal Tournament, the latter uses S3 compressed textures in. I'd argue that including the Savage increases the systems compatibility. One future possible improvement wold be to install a PCI Savage and keep this only for Metal games.

Peripherals

Now I had to consider how the PC would be used. Back in the day I would have had a CRT monitor, basic keyboard and mouse. I'm not going back to a CRT as these things used to give me awful headaches. I do have a 17" non-widescreen TFT. This would serve as a monitor. A basic Microsoft keyboard and mouse with PS/2 connectors. I'll also need a joystick or controller for some games and it's lucky I've still got my Microsoft Sidewinder Game-pad. This little controller is a practically indestructible clone of the Sega Saturn controller - as it was very popular back in the day it provides great compatibility with games of this era.

Ye old faithful Sidewinder Pad, back in action after at least 13 years.

The Play-Test

With all that out the way It's time to see what this thing can do. I'll be using this PC to play everything from DOS games right up to early 2000's titles.  Here's a a few observations made on gaming performance:

Full Throttle and The Dig

Two Lucasart's favourites of mine, I never did complete "the Dig" so I may be tempted to give this a proper go now. Both games worked flawlessly, even the auto configuration in the DOS-based installer detected my sound-card as Soundblaster 16 and it just worked, no messing around! Full throttle is one title that will benefit greatly from having a reliable CD-ROM drive as most of the game is streamed direct from disc during play.

Lucasart's Full Throttle - It just works!

GL Quake & GL Malice

Quake runs very well using both the Voodoo 2 and the Savage 4. The increased resolution and better quality image offered by the Savage 4 give it the edge here, but for sheer nostalgia, the "Voodoo look" will ensure it get's used.

Red Alert and Dune 2000, Warcraft 2 and Starcraft

All these games, while not requiring 3D acceleration, they do require good 2D graphics paired with a  good processor to avoid slowdown. Although truthfully I haven't played much yet, but the graphics seemed to run at a very consistent frame-rate with a large number of units on the screen. I did have to reduce the mouse speed in all the above titles as the scroll rate was too fast. This is usually an indication that processor runs too fast for the game. Starcraft is the most demanding title here, but this system takes it on with ease.

Unreal & Unreal Tournament

Unreal looks just like I remember, plays great with this Voodoo 2 at 800x600 with all the details way up, but I can't help but feel that image quality isn't that great. Trying the Savage with S3 Metal API yields a dramatic improvement in both quality and speed. In the past I couldn't get Unreal to work correctly with my old Savage 3D, but it looks like they had all the bugs worked out of it by the time the Savage 4 reached maturity. It now looks like Metal was the optimal way to play the original Unreal!

Unreal Tournament is a very similar story to Unreal. UT is a little bit more demanding than the original Unreal, so much so that it actually motivated me to upgrade my PC back in the day to an AMD Athlon system. Looking at it now, running on this P2 with 3DFX Voodoo fares a bit better than my old K62, but it can still be choppy at times with a lot of objects on the screen at once. Running on the Savage with the compressed textures also reveals this limitation, while the compressed textures look great, the associated performance penalty would get you massacred online back in the day. So while UT runs well enough to play now, if you wanted to play it "seriously" then I believe a CPU upgrade would still be required to appreciate it fully.

Quake 2, Kingpin and Soldier of Fortune

Quake 2 plays fantastically well on this system no matter what graphics card is used so there isn't any issues here. Image quality wise the Savage is ahead of the Voodoo 2, but a more consistent frame rate is achieved via the Voodoo 2.

Kingpin, based on the Quake 2 engine also plays well on both. I did notice a Gamma issue when using the 3DFX card, the gamma had to be adjusted near minimum in the 3DFX control panel prior to starting Kingpin or the colour would look pretty psychedelic.

Soldier of Fortune is one of those titles that appeared long after it should have. Again, using the Quake 2 engine at the time when Quake 3 was already released was seen as an issue by some people back in the day. Despite Raven claiming the engine was "heavily modified" it still runs very well on this PC, even being able to use the compressed textures and retain very good frame rates on the Savage4.

Quake 3, Return to Castle Wolfenstein

Quake 3 engine games such as Return to Castle Wolfenstein don't generally play well with the 3DFX Voodoo card. I've found the Savage 4 proved better image quality and more consistent framerate in these titles. Although the performance is decent enough to play, I think a CPU upgrade would probably be very beneficial to these titles.

BladeRunner
Back in the day I really enjoyed this game, I always thought it was ahead of it's time. The only issue I had back in the day was that it in order to play the game with a graphics card with more than 4MB RAM you had to disable direct draw. Don't ask me why, it worked but it was a pain in the backside having to remember to do it all the time. I'm pleased to say that I haven't had this issue this time around. The game is actually even better than I remembered! An underrated masterpiece.

Westwood's BladeRunner doesn't get the credit it deserves! Great game!

Serious Sam

Although Serious Sam came out in 2001 and the "minimum" CPU spec is a Pentium 2 400MHZ the game runs very well under OpenGL when using the Savage, I can turn up all the details and even used the compressed textures and retain a very playable good frame-rate at 800x600.

With the Voodoo 2 using "voodoo 2 compatibility mode" to make the game playable, all features must be set to minimum and ran at 640x480! It's not clear if this is due to the superiority of the Savage hardware or simply a result the limited time spent on developing support for (then rapidly ageing) 3DFX hardware.


Improvements for the Future

  • Add an additional 3DFX Voodoo 2 to be installed in SLI - this would allow games to be played at 1024x768. 
  • Replace the Power supply with a newer (quieter and more energy efficient) model.
  • A fan speed controller will be installed to reduce noise.
  • A new Heatsink/Fan for the Pentium 2 would be nice as the one I found only had a passive cooler installed and there are no mounting holes for a fan.
  • Upgrade the 17" monitor to at least a 19" one - my my modern 24" monitor has really spoiled me it would seem! 17" just seems way too small.

Conclusion

I've built a solid PC that can play games from 1995 - early 2000's without any issues.It can sit in my living room next to my modern PC without any negative comments from my wife(who generally tells me to throw away the rubbish old PC's cluttering up the nice modern looking house) The system boasts good compatibility with a mix of DOS titles thanks to S3's solid VESA support and Creative's Soundblaster Emulation. The machine can handle a mix of different API's under Windows. Direct3D, Direct Draw, OpenGL, Glide and S3 Metal give it high compatibility with the majority of Windows titles from the early 1995-2000's titles. After this time-frame most games started to look for hardware T&L. Testing later games, the constraint on the system is undoubtedly the P2 400Mhz. While I own a Slot 1 P3 650Mhz I found when trying this that it caused some older titles to run too fast, but being a Slot based processor has the advantage of being easily swapped out. I'll stick with the P2 for the moment, but this, coupled with the need for hardware T&L in newer titles gives me another exciting opportunity to build another system that will cover the 2000-2002 gaming period! :)

Don't forget to leave a comment or give me a +1 if you enjoyed this post! Thanks!

Tuesday, 17 April 2012

To SSD or not to SSD?

When Solid state drives (SSDs) first arrived on the scene the costs were near insane, people experienced mixed/poor performance, disks were quickly failing, owners experienced low lifespan and firmware constantly requiring upgrading - destroying all data on the disk in the process. This up until recently made having a SSD drive very difficult to justify.

The technology seems to have matured over the last few years, there are now more companies producing SSDs and they are being distributed by the large OEMs along with the latest and greatest computers. The reason for this popularity is undoubtedly the very high read/write speeds, low power consumption and silent,cool operation, with these benefits SSD is undoubtedly the next stage in the evolution of persistent storage.

I've been quite wary up until now, favouring my tried and tested mechanical disk; the familiar hums and clicks associated with the disk spindle churning away can be a comforting sound. You know when the drive is busy and when it's struggling to cope. When a drive is near the end of life you can usually hear a screeching noise and this at least gives you some warning if SMART doesn't pickup any errors. Saying that - I always thought it quite strange to have a mechanical bottleneck in your computer - the limitations of all that fast ram and processor can only write/read from the hard disk as fast as that mechanical spindle can churn. In an attempt to make up for the short-fall in read/write performance I've previously used multiple drives in RAID configuration, with each drive added the noise, heat and power used increased.

I first considered jumping on the SSD bandwagon when I upgraded my PC last year, but the costs of SSD still scared me little too much, having been the victim of HDD failures in the past, speed alone is not my sole concern, data redundancy and size of media in the past has played a significant role. When looking at prices for SSDs at the moment you generally pay around £1 per Gigabyte for low-end models - that can be pretty steep considering you are paying £120 for a 120GB drive, the last time I bought a drive so small was probably back in 2003, if I had a 120GB mechanical disk laying around, I probably wouldn't even consider installing it into my computer.

Despite my reservations the lure of all that speed has got me interested. I had been thinking about the minimum amount of space I can justify and what else I might want to use if for. The operating system, programs I use regularly and perhaps a few resource intensive games is what I decided. I checked my current OS/Programs drive and I'm using 160GB, after cleaning this up I'm down to 140GB - still too much data to fit one one of these cheaper 120GB drives. I found that certain companies such as Corsair and OCZ are selling their 180GB models at £165 and £154 respectively - this seems quite reasonable given the cost of the 120GB models, but with anything larger than this the costs rise dramatically. 180GB for me seems to be the reasonable "sweet spot" to install the OS, Programs and a game or two.

I've had a lot of experience with Corsair and generally found all of their products to be good, but OCZ is a company I don't have much experience with, after reading some reviews I'm still getting a very mixed opinion about both drives. Both the drives in my price-range use the same controller, the Sandforce SF-2281 and both make bold promises of read speed up to 525MB/s write up to 500MB/s, both support TRIM, RAID and have a MTBF greater than 2,000,000 hours. Being unable to see any great difference in the specifications and not wanting to annoy the wife too much I chose the cheapest option, the OCZ Agility 3 180GB.

The Agility series from OCZ is analogous of the Intel's Celeron vs Pentium strategy, in that both the Agility and Vertex ranges offer the similar speeds, but the Vertex series is more expensive. The reason for the need to differentiate these two is due to the kind of memory on the board. Agility uses Asyncronous NAND vs Vertex's Sychronous NAND. Synchronous offers more performance, but costs more to produce, it can maintain read/write speeds better during large file transfers and deals better with incompressible data.


Still being a little unsure of the decision I made in opting for the OCZ over my usual Corsair brand I decided to have an expert test it out for me. Unfortunately he was more interested in eating it than anything else.


So now I have my SSD I went about the task of installing it, physically installing the drive was no issue except for one small problem, all SSDs come in 2.5inch format- the size formerly reserved for laptop hard disks. My case is a Coolermaster HAF932 and it doesn't cater for 2.5inch drives. I can't understand why they abandoned the 3.5inch format, this would have retained compatibility with the majority of cases out of there. Some SSDs such as the Corsair model *sigh* come with a little drive bay converter, I would say this isn't really required because these drives have no moving parts, they require neither acoustic dampening or active cooling diverted onto them. I simply installed the drive with some double-sided Velcro tape to the bottom of my case, out of sight and out of mind.

Currently I have a raid 10 setup on my main controller (4 x hdds), this controller has six ports in total, in addition my motherboard has two lower rated ports connected to a Marvell SE9120 controller, generally you want to not use the Marvell controller as the speed can be very poor, these kind of ports are more suited to SATA DVD RW drives etc. As I wanted to check the firmware version on the drive and ensure it was up to date before I started using it I connected up the drive onto the Marvell Controller, ensured it was set to AHCI and then proceeded to load my operating system. I downloaded OCZ firmware update tool "OCZ Toolbox version 3.02.04" and then started the software. Although windows could see the drive and I could copy files to the drive, the software was unable to see the drive to update.

Where the heck is my drive?

I then went reading OCZ support forums and found that many people experience this issue, it turns out that not only does it have to be a AHCI controller you connect the drive to, it must also be the primary controller - poor show OCZ. It also turns out that you can't update the firmware from the same drive your OS is currently running as this is a destructive update, you certainly can't update from USB caddy either. This is now getting a little bit annoying.

I then plugged the SSD onto port 6 on the main AMD SB850 SATA Controller, went into the bios again. Because I'm using RAID on the other ports on this controller I need to set "SATA IDE Combined Mode" to disabled. This should allow these ports to be used for AHCI or RAID instead of native IDE(for DVD RW's etc).

Setting Sata IDE combined mode to disabled

OK, with that done I booted the OS..... again and then ran the OCZ Toolkit....again. You can see from the results below that I'm not a happy camper.


You can see here - It clearly says it's using AHCI


The OS sees it fine, why can't you OCZ toolbox?

In the end the only way I could make it work it was to install Windows onto another drive and install the OCZ drive as as slave,  I needed to use the built-in Microsoft AHCI driver, it failed to detect it completely with the AMD driver.

Hurrah! Finally!


OK now the easy part, I disconnected all my other drives and then installed my Operating system on the new SSD via WDS. The installation took around 15 minutes with my network being the constraint, pretty good.

A common misconception is "boot up time" is from when he PC is powered on until it reaches the logon screen - not true. The boot-up time is from from then point where POST ends until the logon screen. With the Agility installed my boot time with a fresh image, SP1 and all Windows updates and device drivers installed was 17 seconds, compared to 35 seconds with my 4x hdds in raid 10 setup. Not quite the seven seconds that some other people have reported, but still fast.

To put things into perspective here is the the relevant hardware I am using:
  • AMD Phenom II 1090t Processor @3.2Ghz
  • Asrock 890FX Deluxe 4 Motherboard
  • 16GB of Corsair Vengence DDR3 1600 RAM
  • 4X Seagate ST3500418AS 500GB HDDs in Raid 10 using the on-board AMD Chipset SATA Controller.
The disks in this configuration give me a Windows experience index of between 6.1 and 6.2 depending on whats running when performing the test, with the OCZ Agility I get 7.8.

Windows Experience index gives the drive 7.8

Running under my RAID 10 config under HD Tune 2.55 It shows me I have a maximum Transfer rate of 257 MB/sec and average of 197.6 MB/sec it's certainly no slouch.



Running HD Tune with the SSD however is in a totally different league with a maximum of 324.7 MB/sec and average of 271.7 MB/sec, although I do worry a little bit about the low minimum transfer rate.



I installed Battlefield 3 onto my Agility and this is where I really saw the benefits of SSD, before it would take quite a while to load the game up for the first time, the time between changing levels has been reduced dramatically, it's just a shame that everyone else hasn't got one of these as I find myself still waiting for other people to load up!

Although I'm pleased overall with the drives performance, I can't but help feel a little conned, the drive read/write speeds are nowhere near the advertised 500MB/s, whether this is due to the controller on my motherboard, AMD's drivers or the drive itself is difficult to say. I'll defiantly keep using the drive, but due to the small capacity it's likely it won't be long before it gets full up. I can see the future in the technology of this little drive, but in order to replace the traditional disk, they need to work on increasing the capacities while keeping the costs down. Software is another area in dire need of improvment - the OCZ workbench is a completely useless tool, I can only hope that the firmware installed on my drive isn't as poorly coded.

Sunday, 8 January 2012

SCCM Operating System Deployment Task Sequences

In  the past few months my business has been working on the move away from XP/Altiris to a Windows7/SCCM 2007R3 environment. I was working closely with an outside contractor to get the infrastructure in place and getting SCCM up and running, but before this was even completed I was tasked to begin considering how to perform operating system deployment (OSD). Looking at SCCM from a newbie perspective I will talk about the challenges I faced in getting my OSD to work successfully.

After some investigation I soon found out that SCCM offers multiple ways to deploy an operating system to new machines and also machines already on your network. So far I have tested and implemented the following:

  • PXE boot environment with unknown computer support - I have put a password on this at the moment so that users can't unknowingly image a newly added machine. This is useful where you might be in a scenario where you unbox and build multiple machines at one time, you really don't want to be messing around writing down MAC addresses to import for hundreds of PCS at a time.

  • Bootable WinPE CD/USB stick, this method means you don't have to enable a PXE server on the network and is useful in environments like mine that already have multiple PXE servers. Unfortunately this means you will have to manually import the machine MAC address and put it into the OSD collection before it can be installed.  The disadvantage here is that you end up with a duplicate system in SCCM once it is renamed, but providing you have scavenging set up it should disappear reasonably quickly.

  • If the PC you image is an existing PC with a previous OS (WinXP) you can simply for an install of the SCCM Client and then put the machine into the OSD collection. This can be very handy, but again it will create a duplicate machine in SCCM, which will be marked as "obsolete". This appears to be by design to avoid endless build cycles.

  • Stand-alone task sequence media on CD/USB stick for the entire task sequence onto a DVD - this method works well for remote/small offices that don't have any server infrastructure, but SCCM task sequences can be rather large, in my case I need 3 DVDs worth to fit my standard image. It looks like high capacity USB flash drives are more feasible in this scenario.
Task sequence media is easily created, simply go to "Operating System Deployment" > "Task Sequences" > select your OSD task sequence and click "Create Task Sequence Media"


You can then select the type of media to create or create an ISO of the image for later use. Coming from an Altiris background I have to say I was very impressed easy this was and how well this solution worked.


I've got ahead of myself a little bit here, the largest part of this was the creation of the task sequence to begin with. I was fortunate that I had a base Windows 7 install.wim. Unfortunately it had only been tested on a handful of different models of PCS. After an evaluation of my asset management database I found that I actually had 11 distinct types of desktops that would support Windows7 in my environment. At this point I got a bit of headache, thinking back to Altiris and the multiple images for Windows XP. I wanted to get away from this and have "one image to rule them all".

One Image to Rule them All

The first thing I did was to test my Boot.wim with each device to ensure two things:
  1. Each device could successfully boot to WinPE image.
  2. By pressing F8 during PE boot and using the command prompt I could verify that WinPE could see the Hard Disk Drive and Network Card.
Fortunately all devices booted to WinPE without issue, but some were missing the network card driver or storage controller. These would have to be injected to the Boot.wim before we could continue. This can either be done by mounting the image using DISM in Microsoft MDT2010, or in SCCM you can go to "Boot Images" > right click on your boot.wim and go to properties, then press the "Windows PE" tab, press the "Sun" icon and then select the drivers you want to be injected. In order for the drivers to appear on this list you will have to firstly import them.


Now I had a working preinstall environment I could then begin testing deploying my main image. The next thing I done was to visit the manufacturer websites and download all existing drivers for the products I wanted to move to Windows 7. I downloaded the drivers for eleven models in total and stored them neatly on my SCCM server, sorting by model and device type. I then had another decision to make.

Order Vs Chaos

After some research it would appear there are two ways to approach driver management. One being "Chaos" whereby you simply import every driver possible and then allow every machine being built to scan then entire available driver database.  The "Order" solution is a very controlled environment whereby you import drivers for each model into a package and apply only that specific package to its relevant model. Being lazy I liked the sound of Chaos, but In practice I found this method to be much slower at building machines; the more drivers there are available the longer Windows takes to sort through and determine which driver is the most suitable.


Fortunately, SCCM makes importing drivers very easy. Simply create a new folder in the drivers section, right click, select import and browse to the location you stored the drivers for that specific model.

I was surprised to find that even when you select x64 drivers only that the packages also seem to contain XP, Vista, x86 drivers too. If you are going to import the packages for an x64 image like mine make sure to remove these drivers.


Either click new package to create a specific package or select an existing package, ensure to tick "Update distribution points when finished" to ensure your drivers get sent to PXE for immediate use.


Trying to adopt the "Order" method was causing me to run into issues. SCCM doesn't like it when you try to import a duplicate driver. It turns out that it's quite common for several HP laptops and desktops to share the exact same hardware, this was causing an error when trying to import this driver even although I just wanted to put that driver into my specific machine package. To get around this I installed patch KB2213600 which will allow SCCM to import duplicates.

With this method I was left with eleven different driver packages which I could apply. The next question would undoubtedly be how does SCCM know to apply that specific driver package? 


Using  a WMI query to select the model name from the system bios as a condition for installation allows only this package to be installed.


It's not only drivers that benefit from this functionality, what about the differences in software between laptops and desktops? You won't want to install certain software such as a VPN client or a mobile connectivity suite on your desktops!  Luckily there are a couple of easy ways around this.

Below shows and example using the "IsLaptop" variable - note that this is only availble when you have MDT integration. Before checking for this variable you will need to perform a "Use Toolkit Package" and  a "Gather" from the MDT menu. 

This also seems to work bothways. IE you can use "isDesktop"



You can also check for the presence of a battery.



Hardware Based Applications

When I had created all my packages and performed some test builds I noticed that there were some systems that just wouldn't install the drivers without its accompanying piece of software. ATI and Nvidia graphics packages seem to be the worst culprits, as both rely on their "Catalyst control centre" and "Nvidia Control Panel" to offer any advanced functionality. Bluetooth drivers were also the same as each device requires its own custom Bluetooth stack. I read elsewhere that these types of programs were called "Hardware based applications" being that they blur the lines between drivers and software. I found the simplest way to deal with these is to treat them like any other piece of software. Referring to the suppliers documentation *cough* and after fiddling about I found all the required silent install switches.

So far I'm about 90% there towards finalising the build. There are always little tweaks to go back and add. The other big part of this will be a brand Active Directory/Group policy re-structure which will go a long way to configuring this build. I don't want to add too many registry fixes into the build, but inevitably these will keep coming. At this point my OSD task sequence looks like this.




Please note that grey items are currently disabled experimental steps I was toying with. In the end I don't think I really need these. Using the above I can perform a zero touch installation on a new out-of-box PC or reimage an existing machine by simply dropping the PC into the OSD collection.

Like I said, I'm still an SCCM newbie and I would appreciate any advice on improving this.

Andrew