To start off this post which I have a lot to say, I will use the 2 words "intelligence" and "negligence" in the same sentence. You don't often hear that, but I think it sums up several experiences I have seen so far with SCCM prerequisite checker. I have had the privilege of doing several live upgrades at different organizations and found that in each there are significant warnings and errors in the prereq checker.
Let's start off with the basics. You should always run the prereq checker before the installation of SCCM whether you have a fresh install or an upgrade. Fresh installs seem to be fairly straight forward and generally require a few hotfixes. Now, I will rant for a moment that Microsoft has made it ridiculous to lead you to an update that you have to give your email address to have an email with the download link and then a STUPID password to unlock the update. Really... why do you folks do that? The only plus that I can give is that the email comes generally within 5 minutes, but still.... can we please stop the madness? A password for a hotfix you requested and was sent by email to you??? 
Ok, this is a serious post, so read on.... Now the real fun begins for those of you who are doing upgrades from SMS to SCCM. I'm willing to bet that most of you run the checker and read what's in the wizard and get the hotfix and try and figure out why you have some of the other warnings and or errors. Warnings will allow you to upgrade / install fresh and errors will forbid you from upgrading. Sounds fair and this is where from the first sentence I use the word "intelligence". When you get a warning and or error, you just double click and it gives you general information on the error. There is one awesome warning that I can't remember for the life of me, but you double click on the warning and it gives such a description that the whole explanation is given and says to download at: and it ends.... where is the link?
Here is the good and the bad. You have to know that the ConfigMgrPrereq.log is located on the root of C:\. Open the log file (SMS Trace: newbies) and look for the warning such as the ones in the image below. There, for that specific warning (mentioned above) you will get the link. I think it's too funny, but maybe not... hmmm...
So, errors are critical, but not always accurate. I had a critical error the other day and a reboot fixed it. I had a warning that there was a backlog of files and (if you look in the log file) it was only 2 files that were 2 days old. I'm thinking of the times when discovery happens too fast for SMS or SCCM to process and you have an inbox with over 100,000 files... not the case. 2 FILES CAUSED THE WARNING! Those files were the only 2 files in the Despooler inbox.
There is another MAJOR concern with warnings. There is a warning that states something about your DP's may not be updated with the proper version. This should have been made a STOP error by Microsoft. I ignored this and it killed the install and we had to restore the server from backup. YES, always backup your server and SMS before an upgrade. Don't get stuck in a bind and get your client or boss's panties in a bunch because you skipped a critical step. On this particular issue, you get to the install point and the components are installing and half way through, you get a blue circle and a blue circle at the bottom of the page. This is NOT good. You need to make sure you have the proper version of the package on all the DP's. This error happens generally when (and I don't know why people do this... sorry) a package is made and it's never sent to a DP. Once it's sent to a DP, a HASH is made in the SQL table. If there is no hash, then you get the warning.
Another DP warning is when it tells you that you have a HASH MISMATCH. When I saw BOTH of these warnings in the same log, I thought that fixing one would fix the other. Nope.... They are both very different and have to be dealt with.
Bottom line, all errors and warnings should be fixed as much as possible except the ones where you know it makes no difference. One example of that is when you get the warning about an operating system not being at the proper version. Yes, some people still run operating systems under Windows 2000 SP4. There should be IT police for this sort of behavior, but that's another post.
Let's get dirty (no not that way... all you IT folks are the same.. LOL)! I spoke about the log file and that is the topic of the conversation. Whether you have errors or warnings, you MUST read the log. the log gives you MUCH more info than the wizard. Not only do you get what you see in the wizard, but gives some interesting solutions to fix the issue(s). Notice the image below. I have copied one of the queries below. You copy the query and run it in SQL 2005 to find the problem.
SELECT GSYS.Domain0, GSYS.Name0, site.SMS_Installed_Sites0, GHSYS.Domain0 AS 'Previous Domain', GHSYS.Name0 AS 'Previous Name', GSYS.SMSID0 AS SMS_Unique_Identifier0 FROM System_DATA GSYS JOIN System_HIST GHSYS ON GSYS.MachineID = GHSYS.MachineID JOIN System_SMS_Instal_ARR site ON GSYS.MachineID=site.ItemKey WHERE GSYS.Name0!=GHSYS.Name0 UNION SELECT RSYS.Resource_Domain_OR_Workgr0 as Domain0, RSYS.Name0, site.SMS_Installed_Sites0, GSYS.Domain0 AS 'Previous Domain', GSYS.Name0 AS 'Previous Name', RSYS.SMS_Unique_Identifier0 FROM System_DISC RSYS JOIN System_DATA GSYS ON RSYS.ItemKey = GSYS.MachineID JOIN System_SMS_Instal_ARR site ON RSYS.ItemKey=site.ItemKey WHERE RSYS.Name0!=GSYS.Name0 UNION SELECT RSYS.Resource_Domain_OR_Workgr0 as Domain0, RSYS.Name0, site.SMS_Installed_Sites0, GHSYS.Domain0 AS 'Previous Domain', GHSYS.Name0 AS 'Previous Name', RSYS.SMS_Unique_Identifier0 FROM System_DISC RSYS JOIN System_HIST GHSYS ON RSYS.ItemKey = GHSYS.MachineID JOIN System_SMS_Instal_ARR site ON RSYS.ItemKey=site.ItemKey WHERE RSYS.Name0!=GHSYS.Name0
Above is a warning I had and I ran it against the SQL DB for SMS_XXX and found some interesting things. First, some queries work ok and some don't. Always check the query before executing it. This is the part of the first sentence where I use the word "negligence". Some of the queries work and some do not. If you run the check and get an error, sometimes Microsoft has quotes "XXXXX" and the proper query should be 'XXXXX' with a single quote. Check the results when you get the proper query string and determine at that point what needs to be fixed. Sometimes it's just a hash issue and you delete the package because it was never sent to a DP.... sometimes it's a bit more. Either way, ALWAYS read and use the log to see what the underlying problem is. I have seen some basic stuff and for a while, thought that I had seen it all, but in the last month I have seen some serious stuff that has taken some quality time to fix.
Finally, just when you feel like your life is all warm and fuzzy, you get SCCM upgraded and all green in the status components and then..... SP1 prereq check.... LOL... here it comes AGAIN. Read the logs and clear out as much as possible. If you lose your SMS data and your hierarchy dies... it's YOUR fault for not backing it up. Hands down..... be smart and remember that you are working with the most complex application Microsoft makes.
I hope this helps you to think about this important, but very misunderstood / respected aspect of the process.
