CoffeeFiend

It totally depends. But for anything more advanced than that, you'd need more "specialized" equipment and a fair amount of knowledge. And in a lot of cases, there is just nothing you can do, short of swapping the proper PCB with the right firmware (might require replacing chips) & everything (might even require a clean room). However, in a large number of cases you will see fairly typical failures that are really easy to recognize. Just by knowing the basic layout of that PCB area/placement of the diodes vs power connector/sound knowledge of quintessential electronics designs, you can already tell from the beginning it's a TVS diode, and that D3 is on the 5v rail (if my eyesight doesn't fail me, it's a General Semi/Vishay SMBJ5.0CA), and that when you apply 12v to it, it will do its job (conduct so the voltage doesn't damage anything), and then short (being a silicon device) when it fails, ending up with the result we see here. Applying 5v on the 12v rail won't make the other diode clamp, and D4 seems to be intact as well. It's one of the easiest problems to spot and understand on a hard drive. Well, it's pretty easy going across the different supply rails (3.3v, 5v, 12v) and ground to see if you have a short (or even across the TVS diodes directly; diode check mode works well for this too), but what you can do with a multimeter alone is fairly limited. It's a very good, essential yet basic tool (although you still have to know what you're doing). And it doesn't have to be crazy expensive, I've seen $400+ multimeters that sucked in many ways when compared with models 1/4 of that price. Also, fancy and expensive tools are only useful in the hands of those that know how to use them e.g. a $25000 LeCroy oscilloscope wouldn't have found the problem for you (it's merely a really expensive paperweight in the hands of a n00b) That totally depends what you're trying to accomplish. If you just want to see if various protection circuitry on the power supply side have failed (and similar simple things), you rarely have to. Actually, a large numbers of multimeters have had that function for a long time Not that it is very practical in most cases admittedly (having to de-solder, SMD parts not having long leads, etc) I don't see how that would even help here (or with most hard drive PCB repairs for that matter) Of course it's not a perfect 0 ohm. Even a piece of copper/silver that length near absolute 0 degree doesn't have a perfect 0 ohm resistance. It's very close to it however (usually about 0.01 ohm -- something most DMM's can't measure anywhere near accurately). I take it you've never worked with SMD parts. SMD resistors don't have color coding. They do have markings "just like other components". A single zero like here, or 3 of them (I see those a whole lot more of those around here) does mean zero ohm. Again, if it was merely plugged backwards and that the protection did its job like it normally would (and by judging the look of the TVS diodes it seems to have; I'd bet good money that D3 is shorted), then he should be able to get it to work without resorting to that. The TVS diodes are merely protections (read: optional). If after removing them you don't have a crazy short on the 5v or 12v rails anymore, then most likely it'll work just fine (there's always a remote chance damage was done to other components in the picosecond or so before the TVS clamped). It's definitely good enough for data recovery (I personally wouldn't want to keep using that drive long-term, even with a new PCB). Incurring cost (and waiting for parts) to replace the entire controller vs "repairing" it in about 5 seconds for free, just to recover data doesn't necessarily sound smarter to me. Then again, if it's still shorted after doing that, I would get another controller, for sure. Mind you, even that may not work then as one of the sensitive things that might fry if the TVS didn't clamp fast enough is the preamp located on the head stack (good luck changing that yourself!)

eSATA is lots faster than FW 800, it comes on most new motherboards, whereas FW is quickly losing popularity (not that it ever got really "big" in the first place; and daisy-chaining here means a shared bus). eSATA is also cheaper (the controllers, the enclosures and the cables). It seems like the most logical way to use a storage device i.e. its built-in native interface, instead of going through a converter. Also, keep in mind USB3 is coming. The adapters are already inexpensive (about $35 for a PCI-e card with 2 ports last I checked) and the speeds should be amazing (more than 4x that of FW 800, faster than eSATA too), and being USB you can pretty much assume you'll soon find those on pretty much everything. You can take any old USB device pretty much anywhere and it'll work on basically anything (it's truly ubiquitous), whereas FW...

The design of that power area of hard drives is fairly classic. You usually have 2 TVS diodes, one for the 5v and one for the 12v. They protect against reversed polarity and voltage spikes. So if you don't plug it backwards and that your PSU isn't faulty, the drive will happily work without them (if it's for data recovery only, I definitely wouldn't bother). They're fairly big as well, it shouldn't be hard to remove, even for someone inexperienced. What most likely happened (and that people never want to admit), is you plugged the drive backwards, which will do exactly what we see here (admittedly, it's harder with SATA connectors but lots of times they're on adapters) As for the resistor, it is indeed a 0 ohm (in the last picture at least), so you could just short the two pads (and nothing else around it, obviously) with solder instead. That is assuming it was plugged backwards, and that only the diodes are bad. If something else is short elsewhere on the PCB, it might not be a good idea, so I'd check the resistance on the 5 and 12v buses (with any old digital multimeter) before I power it on first (if it's near 0 ohm, you DON'T want to plug that in your computer). Feels like I'm repeating myself

Not a bad pick/value. Here is the list of supported CPUs. Personally, I'd probably go for a AMD Athlon II X2 250. It's a tiny bit faster than the 6000+, but the 6000+ has a 125W TDP and the X2 250 has a 65W TDP. The power reduction will pay for the difference ($10) in well under a year. A ~40% faster X3 425 would be another extra $10, if you can spare it. I don't see how it would have a "significant disadvantage" in terms of speed though. Yes, the HT link is slower, but that will hardly change anything (it's not much of a bottleneck). Ditto for DDR2 vs DDR3.

It totally depends on your budget and which games you'd want to play and all that. Then again, I can't find any information about this motherboard whatsoever, so it's just about impossible to know what it has or supports. The best we can do is guess what it might support, based on guessing it most likely has a Intel 965G chipset. Either ways, your main limitation for mostly anything seems to be the CPU. You *might* be able to drop an inexpensive dual core CPU on there. Even a $50 E3300 would be a huge improvement over a P4 3GHz (about 4x faster or so), but again I have no idea if your board would support anything newer than a P4. You will have to find out what it supports first, or buy something hoping it might work (bad idea), or buy a new motherboard and CPU. As for buying a new CPU and motherboard, there's a LOT of options... I wouldn't personally be buying something based on Socket 775 + DDR2 indeed. But the i3 isn't exactly a great value IMO, and i5/i7 doesn't seem exactly what he had in mind ("While I don't have a specific budget in mind, its not going to be too high."). Price of a basic i3 upgrade: Absolute cheapest (and slowest) Core i3 (530): $120 Basic Gigabyte 1156 motherboard (GIGABYTE GA-H55M-UD2H): $105 4GB (2x2GB) DDR3: $100 or more depending on brand and speed/voltage/timings Total: $325 or more... No need for a new PSU with that board (assuming it's a decent 500W) If you want a i5 750, just replace the i3 for the i5 750 (it's also 1156, not 1366), and you're up to $400+. As for AMD, you'd likely go with a socket AM3 board & DDR3 RAM. Same prices for RAM, and a decent board would cost about the same too. The main difference is the CPUs have more value for your money. In general, you can have the same performance as the i3 for about 60% of the price. AMD are a somewhat better value (performance/price). Intel is a better pick if you want the really fast CPUs though.

Your motherboard has a PCI-e x16 slot, there's no reason it wouldn't work.

Why wouldn't it work well? I've done lots of conversion using XP, Vista and Win 7 and all work just fine. Not that I see any point converting an mp3 to such a large format (trying to preserve quality that isn't there in the first place?), it would just waste disk space.

You can get the infos using WMI fairly easily. See the documentation for the Win32_CDROMDrive WMI class. Here's a quick snippet with the relevant properties included: strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_CDROMDrive") For Each objItem in colItems Wscript.Echo "-----------------------------------" Wscript.Echo "Win32_CDROMDrive instance" Wscript.Echo "-----------------------------------" Wscript.Echo "Caption: " & objItem.Caption If isNull(objItem.Capabilities) Then Wscript.Echo "Capabilities: " Else Wscript.Echo "Capabilities: " & Join(objItem.Capabilities, ",") End If If isNull(objItem.CapabilityDescriptions) Then Wscript.Echo "CapabilityDescriptions: " Else Wscript.Echo "CapabilityDescriptions: " & Join(objItem.CapabilityDescriptions, ",") End If Wscript.Echo "MediaType: " & objItem.MediaType Next Capabilities *should* include 4 if writing is supported. Hopefully it should be a fairly reliable check. Otherwise you'd have to dig into IMAPI (v2 preferably, most likely using C++) which is a whole lot more fun.

You're welcome... Mind you it's barely worth being thanked for, I wouldn't call this a "production-grade" script. It's not tested enough to begin with. I hope the WMI part doesn't mess up on you (that's always the tricky part) -- it accounts for empty strings (IsEmpty) as well as zero-length strings and single "space" characters which it tends to return (WMI can always be tricky like this), but then again one could have checked it's length instead (i.e. that it's > 1 which would arguably be better -- then again parts of it suck by design e.g. including the TSV file's header row in the array). It also assumes the account running the script has sufficient permissions to set that registry value (no errors are displayed when it fails, no logs created or anything). If the user accounts had sufficient permissions, then you could also set the computer description in AD (trivial to do, an extra 2 lines or so), but I wouldn't personally give the users these permissions. You could have another script that enumerates PCs from AD (trivial to do), runs the exact same WMI query to get the asset tag but against remote computers instead of locally, then matches it to a RES-xxxx tag (100% identical code), and sets it in AD (just run the script with an account that has sufficient permissions for this task). Although I would definitely prefer cscript here so you can do console output (show asset numbers & res tags; and also log them of course). Still quick and easy, but it would be a little trickier to test over here not having the same AD tree I'm going with the sample you provided us with, specifically: a TSV file (tab separated values a.k.a. tab delimited). It might not be obvious if you open the file with notepad but it's a tab character between both columns and not a space, hence the chr(9) in the script. If it was a CSV file then it would be a comma instead. So you export your list from excel as a TSV file, and change the extension to .txt, just like you have before. If you want to use a comma or a space, there's a couple lines where you'd have to change minor things. If you'd rather use another file format (CSV, flat text file with spaces, any database, a web service, etc) or language just let me know

I fail to see the problem. I don't see how it matters if it's run against 5 computers or 5 million. It's the same amount of work to write the script regardless. And if anything, I'd rather it be ran against more, so I know I'm not wasting time for nothing (I wouldn't bother if it was for few computers) and it saves someone actual time. That is why we write scripts after all, saving time from doing time consuming tasks by hand. It's only a matter of gluing 3 little snippets together anyway: get service tag from registry matching it with a line inside a simple text file setting a registry value each snippet being already written for you for the most part. It's quick & trivial to do. So here goes, and sorry for taking so long to get back to you. It's barely tested, and on Win7 x64 only. No error handling to speak of or anything fancy (could have matched it using a RegEx, could have added logging, you could fetch matches from a simple database instead or even a REST web service, etc). It should still work fine. Sorry for having to attach it, but the [ code ] tag screws up lines (splits them in half), and the [ quote ] tags strip all indentation... You will have to rename it to .vbs obviously. Edit, it looks like the line break thing is fixed, now it's only the colors that are a bit weird: Option Explicit On Error Resume Next Const tsvfile = "\\Your-Server\Network-Share\Path\servicetag_resourcecode.txt" 'service tag -> resource file const HKLM = &H80000002 Dim oWMI, oFSO, oReg, f, strTsv, colItems, objItem, strSvcTag, strRes, blnMatch 'get service tag strSvcTag = "" Set oWMI = GetObject("winmgmts:\\.\root\CIMV2") Set colItems = oWMI.ExecQuery("SELECT * FROM Win32_BIOS") For Each objItem In colItems If (Not IsEmpty(objItem.SerialNumber) And Trim(objItem.SerialNumber) <> "") Then strSvcTag = objItem.SerialNumber Next If strSvcTag = "" Then WScript.Quit 'no service tag to work from 'find match in TSV file Set oFSO = CreateObject("Scripting.FileSystemObject") If Not(oFSO.FileExists(tsvfile)) Then WScript.quit 'no file to work from Set f = oFSO.OpenTextFile(tsvfile, 1) 'ForReading strTsv = f.ReadAll 'read the whole tsv file in one fell swoop to minimize I/O f.Close ColItems = Split(strTsv, vbCrLf) blnMatch = false strRes = "" For Each objItem In ColItems If left(objItem,len(strSvcTag)) = strSvcTag Then blnMatch = true If blnMatch Then strRes = right(objItem, len(objItem) - instr(objItem, chr(9))) Exit For End If Next If Not blnMatch Then WScript.Quit 'no match 'set description in registry Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv") oReg.SetStringValue HKLM,"SYSTEM\CurrentControlSet\services\LanmanServer\Parameters","srvcomment",strRes script.txt

It's pretty straightfoward, but we need a little more infos. What list? Where is it located (read from a network share perhaps)? In what format is it? CSV or whatever? Detailed infos required here: column order, formatting, is there a header row? etc. Ideally you'd provide us with a sample. Getting the service tag is trivial (no need for wmic, vbscript has everything needed built-in -- in fact, ~95% of this whole thing is a simple copy/paste job, along with some minor changes to glue the parts together). Setting the description in the registry is also trivial, however, don't you want to set the description in active directory as well?

In theory it's better. In practice, in makes basically zero difference. Precisely it would be 0.6% faster overall, according to tomshardware. Hardly worth paying $200 to $300 extra for, especially when your main bottlenecks are elsewhere (disk I/O speed, GPU's 3D power for games, etc) Nope. It'll just run at a lower clock speed than it's able to. Yes, but idle power consumption isn't the same for all CPUs, and that kind of information can be a pain to find. Either ways, I personally try to stay away from higher TDPs. So you haven't said anything about needing a crazy amount of RAM, you don't care for SLI or CrossFireX, and I doubt you'll be going for a $1000 6-core beast. So I don't see the point of going with an expensive LGA 1366 system here. That extra money would better be spent on a SSD (faster booting and apps opening faster), faster video card (nicer graphics in games), faster CPU (faster at encoding HD video or rendering), more disk space or something along those lines (depending on what your needs/usage of your computer).

Both processor series use a different socket. The 800 series (much like the i5 and i3) use the LGA 1156 socket. This is their mainstream stuff that's good enough for just about everyone. The 900 series uses the LGA 1366 socket. That is their "enthusiast" solution, and it's priced accordingly! If the 4 DIMM slots of the LGA 1156 setups is a limitation you can't live with, then you want this. If you really need that über SLI or CrossFireX rig and need a large amount of PCI-e lanes for it, then 1366 is for you. If 4 cores isn't enough for you, then again you want this (mind you, the 6-core 980X is over $1000 and is unlikely to be cheap anytime soon). If you have extreme needs then they have that solution, but it will cost you. Not only the CPUs cost more, but the boards also do -- easily another $100 e.g. $230 for the "standard" ASUS P6T (1366) vs $110 for either an ASUS P7P55-M or a P7H55-M PRO (both 1156). Also, the TDP of those CPUs is higher (about 130W vs about 80W for the other socket), which means more heat and a higher power bill. Then again, I wouldn't overlook AMD. The Athlon II X4 620 gives you 50% more bang for your buck (speed/$) than newer Intel quad cores, and there are lots of great & inexpensive boards. Intel has some faster CPUs but they sure cost more. For example, the i7 930 is 2x faster but 3x the price of that X4 620 ($300 vs $100). Or even if you go mainstream, the i5 750 is about 35% faster than the X4 620 (hardly impressive), but at double the price ($200 vs $100). Also, AMD is supposed to introduce 6-core CPUs next month as well (Phenom II X6 1055T and others) which should cost a lot less than $1000 too.

Usually it's pretty straightforward. For msfn it surely is. You can even try using plain old telnet: telnet 67.19.16.68 80 GET /board/ HTTP/1.1 Host: www.msfn.org (followed by enter twice) Works fine (you can see the markup fly by). Some sites require a few extras (e.g. "User-Agent: cloned-user-agent-string-here") but most of the time this is all you need. Obviously, some sites require authentication to download files.

You have to remove ",,48" from this for it to work (otherwise colItems can't even be evaluated, so there is nothing to pass to the GetKey function) However, the SerialNumber property of that WMI class returns the ProductId, NOT the DigitalProductId so it won't work regardless (you can't "decode" that)

Did you copy the .exe locally, or are you trying to run it from a network share? If you're running it from a network share, you will most likely have to change that zone's security settings in order for it to run.

It's mostly a different syntax. VB ".Net" looks fairly similar to older VB in syntax ("Dim" to declare vars, no semicolons, etc) C# has a syntax more like C, C++ and other C-ish languages (plenty of them) It's a matter of preferences. Ideally you'd know both (it's not that hard really). VB syntax can be handy sometimes (e.g. for vbscript or VBA stuff), but the C-style syntax is way more common overall. Either ways, the main problems for most people coming from the older VB are learning OOP (very important for any language) and knowing their way around the .Net framework. Not so much a particular language's syntax.

Because terminal services on Server2 ain't listening on port 6789. You would have to change the destination port (source stays 6789 or whatever you setup, but destination port would have to be 3389 (on Server2's IP obviously). That's assuming your router supports doing this (I've never tried the WRT610N). Then it should work just fine. If it doesn't, then you'd have to change the port terminal services listens on indeed.

That's not a MS Office 2010-specific thing. Even for older versions of Office (including 2003 and 2007) you must do this, as the path (GUID) changes with the language, SKU, service pack, etc. There's just no way around enumerating the subkeys (at least, to properly do it). And it's not uncommon that there are more than one subkey containing a DigitalProductID as well (e.g. for visio or the visual studio web authoring component). And don't forget that with x64 versions of Windows, you also have to take into account reading from Wow6432Node or not (using KEY_WOW64_64KEY in your RegOpenKeyEx call; obviously you must check for a x64 OS first), especially since there is now a x64 version of Office 2010 which writes outside of it. Also, I believe versions of MS Office activated using MAK keys (or was it KMS?) don't store keys that way (you'll just read something invalid). I haven't tested this very much though. MS Office 2010 apps (and a few others) indeed use a new type of DigitalProductID4 which is a little bit different. I figured I'd finally share some of the infos (although it's still subject to change until it RTMs): to decode those, you have to change your offset from 52 to 0x328 (obviously you need a bigger buffer to hold the new larger DigitalProductId) and then decode it the old way. Getting the "edition" of the suite can be tricky (I don't use the registry for this) as ProductName isn't always there. Sorry, I'm not sharing my code It's not Delphi or VB either ways.

It's nowhere near as easy as something like vbscript or a simple batch file using reg.exe or the like. vbscript wins here, hands down (could anything be easier than BASIC really? That would have to be like Logo ) It's definitely not fast(er) to write, and as for execution time, basically all methods are measured in ridiculously tiny fractions of 1 second (instantly) so I think it's pretty much irrelevant. I'm hesitant between a tie, or a win for vbscript (mostly for being quicker to write) With all of these methods, no "3rd party" interpreter is required, it works out of the box (unlike say, a non-compiled autoit script). I fail to see how this really matters when you look at the big picture. I'd call that a tie, mostly because I fail to see the relevance (much like it doesn't really matter when I read a web page if it was served as static HTML or generated by an interpreted PHP script -- ultimately it's the content that matters to me, not whether if it was pulled from disk or a database) Actually, the scripts (vbscript/jscript/batchfiles at least) are mostly self-contained, as in they need nothing extra installed on freshly installed copy of Windows (no runtime or anything to install). Whereas with most programming languages... not so! With C++ you'd often need the MS VC++ redist (2005 or 2008, with the proper SP), with C# or VB (".Net") or C++/CLI you'd need the .Net framework installed, for older VB (yuck) you'd need the VB runtimes installed and so on. And if you're making reference to the script relying on standard, built-in components of Windows (like cscript) to run, then so does you app (using many DLLs like advapi32.dll for the registry stuff and so on). vbscript wins here too. Just like you can debug a vbscript by passing the //X command line arg. Yet another tie. So what? I fail to see how this matters as well. It gets the job done, it's quick to write, easy to maintain and modify, no need to compile anything, works out of the box, etc. Sounds like a winner to me! Windows admins use vbscript for a reason. It's great for these kinds of things (especially when combined with WMI and ADSI). You can whip up something to do simple tasks easily and VERY quickly, often reusing large chunks of previous scripts. jscript is nicer in some ways (nicer syntax IMO, and also decent error handling) but a lot of admins aren't too familiar with the syntax so it's not used nearly as much. Powershell is slowly catching on too. It's great for a lot of things, once you get the hang of it. A couple quick examples just to show (works out of the box on Win7): 1) How to disable services whose names are listed in disablesvcs.txt (for all the folks into that kind of stuff): Get-Content c:\somewhere\disablesvcs.txt | Set-Service -StartupType disabled It's definitely a LOT faster than opening a file (permissions, error handling, etc), reading the names into memory, closing the file, and then iterating through the services one by one looking for a match, setting their properties as you go (or something along those lines)... 2) How to enumerate all the services installed, their running status, and then create HTML out of it, and write that to disk (simple to do, but normally requires lots of boring mind-numbing, time-consuming code to be written, and then debugged and maintained), with PS: Get-Service | ConvertTo-Html | Out-File c:\somewhere\services.html You can do something like this (from scratch) in like 15 seconds flat. Say, you changed your mind, or need to do something slightly different and want to reuse this script (code reuse!), or you just need the info in another format for processing/analyzing it, and it needs to be in XML instead or perhaps CSV? No problem! Just use ConvertTo-Xml or ConvertTo-Csv instead, problem solved. Want to do sorting, picking what columns to display, change the page title or whatever? Sure thing... (Obviously it does FAR more than just playing with services) They're great, time saving, efficient tools, and they most definitely have their uses. They're popular for a reason. I definitely wouldn't want to use C++ for this (that would be crazy, I'm sure it would drive a lot of admins to drink), and even C# would be a real drag in most cases.

The way I see it is, he has too high of a self-esteem to use the industry standard way to do this (vbscript or powershell or even jscript -- batch files would also be usable as well as autoit and several others) because that's too lowly for him, and he would rather waste his employer's valuable time to write a fancy program for something so trivial instead, basically so he can feel good about himself. I very well could be wrong (hopefully I am), but it does sound quite like that to me. Out of that list, I could do it in C++ and C# as many, many others could (it's not exactly hard -- nothing worth patting yourself on the back for). I still wouldn't do that as it would be a pointless, massive waste of time. There is nothing gained by doing it that way (both would execute ~instantly, using very little resources), and it would be an unnecessary pain to maintain e.g. other employees who might have to make changes might not know C++ or whatever, or might not have ready access to a suitable compiler, etc. The script can easily be edited by anyone with plain old text editor, in very little time, using minimal knowledge, works out of the box and all that. It's simply quicker, more effective, easier and better overall.

I don't have a direct answer, but it would be extremely helpful to have more details to figure it out. If you take note of which mac addresses the packets are sent from and also manage to find the culprit, then you can have a deeper look at its settings, and if it's specific to a certain OS. Mind you, I don't see DHCP discover being much of an issue, it's not like your clients are sending out DHCP requests. It might actually just be network discovery.

The video card is irrelevant. The codec decodes the video stream (better bitrate will make for a better picture of course), and then the video card merely outputs that decoded image to your monitor. Fancy gamer cards offer no "picture quality enhancements" that make some bitrates looks better, they all show the image as-is. What those gamer cards do is offer extreme 3D performance, mainly meant for games. So a movie won't look better on a $500 card than it will on a $50 card.

Well, it sounds like it's mainly a region locking thing. There's loads of apps that can get rid of this (if you don't mind having to make a "edited" backup of your DVD), but then again lots of DVD players have "alternative" firmwares (RPC1 or multiregion ones) which will ignore region limitations and sometimes hidden menus to set those things. Your player may also not like playing NTSC content either, in which case you'd have to resize the image (720x576 -> 720x480) and also perform a framerate conversion (29.970 or 23.976 -> 25 fps) which doesn't always turn out nice.

Like I said before, unless your mobo sucks pretty badly, you'll gain very minimal speed over the onboard NIC. Assuming the GBit NIC on your motherboard has a PCI-e interconnect, you'd gain about 1% speed at most with an external PCI-e NIC. If you're getting a PCI NIC instead, then you'd go down in speed. Honestly, I don't think changing NIC will give you any performance boost as the problem is most likely elsewhere. I would definitely run iperf first.