None seemed to be specific on registry checks without file version check.
Registry checks by themselves, without file checks, are notoriously unreliable EXCEPT when used to determine if a product is NOT installed.
The absence of a registry KEY is always a great indicator that a product is not installed.
As such, the best place to use such rules is typically in the Prerequisite Ruleset.
Ergo, you can test for the absence of the "Visual Studio" key to determine that the update is not applicable,
but to determine that an update IS applicable, you should really test for one or more of the actual *FILES* (by File Version) that are going to be replaced by the update.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\VC\Runtimes\x64]
"Version"="v11.0.61030.00"
"Installed"=dword:00000001
"Major"=dword:0000000b
"Minor"=dword:00000000
"Bld"=dword:0000ee66
"Rbld"=dword:00000000
Can anyone give me the proper Applicability Rule and Installed Rule to check if it's there to not install it and if it isn't to go ahead and install?
First, since you're apparently checking a VALUE in the registry, it now matters which of the four "Registry Value" rules you're actually using:
- Registry DWORD Value
- Registry Expand String Value
- Registry String Value
- Registry Version in String
Since you're looking for a four-part dotted decimal value, it should be stored in a STRING value, and you should be using the "Registry Version in String" rule type.
Second thing I'll note is that the VALUE for your "Version" field is incorrectly formatted. It should be a simple four-part dotted decimal number. Lose the preceding 'v'.
e.g. "Version"="11.0.61030.0"
If the VENDOR stores that value with a preceding 'v', then you'll have to use the Registry String Value rule type, and you can ONLY test for equality.
Third, and potentially problematic depending on the above, an Applicability Rule should always be defined as a LESS THAN comparison, so for Applicability you're not looking for something that matches, you're looking for something that's older than what it should be, and you want it to evaluate as TRUE (TRUE that the version currently on the system is OLDER than the version that will be put on the system if the update is applicable). For the Installed Rule, you should be looking for something that matches (i.e. EQUAL TO) -- the *correct* version is already here.
Finally, since it seems that you're testing for a 32-bit app on a 64-bit system, rather than explicitly checking the 'Wow6432Node', try checking the natural node, and checking the "Use 32 bit registry" checkbox. One of the advantages of doing this is that you can then use the same package for BOTH 32-bit systems AND 64-bit systems. The rule as implied above can only be used on 64-bit systems. (Although I'm curious that you'd be checking for something in the x64 subnode of ~\Runtimes in the Wow6432Node.)
Lawrence,
Thanks very much for the detailed post. It does give more insight into what should work for testing.
It is in fact a 64 bit application from Microsoft. This is a link to the site for download and the file is called vcredist_x64.exe
http://www.microsoft.com/en-US/download/details.aspx?id=30679
Part of the problem is they always call it the same file name when they do updates. And the updates are not really updates as much as here’s another one to install as well because we left some stuff out from the last one that you may have needed too.
So we end up installing every version.
I found that registry as being the one to monitor that gets added and removed during install and uninstall. I know this doesn't help if someone manually deletes the files it creates but I’ll deal with that if it happens.
I was going to do file to the file exists with registry value except the files they create have different versions than the version of the install.
So as you were saying, I figured I could at least see if the registry key exists with that version number and if not It would install.
Something you brought up as an issue maybe is the “v” in the version number. Microsoft mistake I guess? So yes, I've been using Registry String Value, but maybe I've not been setting it up correctly?
So here’s what I tried based on what you had said about using the Prerequisite. If I understand correctly it should be strictly a False / Don’t Install, True / Install option.
No Applicability Rules and No Installed Rules.
I've tried this with “Not Rule” both unchecked as I’d assume and checked just in case.
In both cases it tries to install on both the machine that does have and doesn't have this registry entry.
So this is where I’m confused as my assumption is that if it fails to find the registry it shouldn't want to install.
I thought maybe for some reason it couldn't scan the registry at all, but if that was the case, then shouldn't it fail and not want to install as well?
I can’t seem to find log files that may say exactly what it is doing during the evaluation process?
As you can tell there are a lot of assumptions being made on my part, and I’m sorry for my stupidity in this matter. You’re help is greatly appreciated!
-Charles
Never wanted to be one of THOSE guys but here I am 
.
Here's the setup that when I publish it, and check for updates on the two machines, they both still think they need it when one does not. Yell at me if I set something wrong.
Prerequisite Rules
Package
Applicability Rules
Installed Rules
Registry of machine it's already installed on:
Registry of machine it's not installed on:
Check the "Use 32-bit Registry" checkbox in all rules where you reference the WOW6432Node tree.
On a 64-bit system, it's going to try to find that node in the 64-bit hive, and it's not in the 64-bit hive, it's in the 32-bit hive.
Done ... same results, both see as wanting to install it.
Applicability Rules
Installed Rules
Think I understood what you where asking for but just to verify, I updated it as follows and same results
Applicability Rules
Installed Rules
No problem, and thanks again for all your help on this. I did a search in the registry originally for 11.0.61030.00 and this is the first thing that showed up. I uninstalled in and it was removed so figured it was the best thing to go after.
On your thoughts for other entries I've searched for 11.0.61030 and more options show up that are also removed when uninstalled, so maybe there is another one to go after ... but why is this one not working is still a question. 
The other ones are mostly uninstall paths and dependencies, except the following:
None of these were found when uninstalled. So maybe one of them is a better choice?
Again, the help is greatly appreciated and take your time as the weekend is upon us
-Charles
Assuming I set them up right, same results. Thanks again for your help today and I'll follow-up with more testing on Monday.
Or maybe tonight remotely after I go walk the dog 
Applicability Rules
Installed Rules
Same thing when I set the windows version to windows 2000 and I'm installing on windows 7, so I'm going to assume at this point it's not even checking for anything properly before it installs?
Further testing.
I uninstalled it from my machine, let windows update do the install, checked for updates and it shows up over and over again, even if I install it through wsus.
Of course it only is installed once in Programs and Features
