Patch Manager Deploying an Executable FIle (.exe)

Hi Taylor,
For .EXE files it isn't *too* much different, but one big one is that in most cases with an .EXE you'll be forced to specify a command line element to make the installer run silently.

When it comes to the Not Applicable message when trying to deploy, there are a number of common things that may be at play there.
The most common (~95%+ of the time) is that the target machine is failing one of the defined Prerequisite or Applicability rules that are defined in the package. 

However, you mentioned you did not define any rules?  I haven't tested it very recently but if I recall correctly you will need at least one rule - and I think that if you don't have any rules it may come back with a Not Applicable result for you.

---------------------- 
Basic info on that (please forgive if you already know all this, but presenting it here for people newer to the product):
Without being too restrictive (to allow it to be deployed to basically any Windows machine), I would generally recommend the following if you just need to make a package for a one-off deployment and don't really care to take time to narrowly define the rules:

Prerequisite Rules:   

A set of rules that says: 
[Rule#1]: "Target machine processor is x86"
OR 
[Rule#2] "Target machine processor is x64"

Alternatively, you could define a rule that defines a Windows version check such as "Target machine must be at least Windows version 5.1 or later"

Applicability Rules: 

• Same guidance as the prereq rules.

Ideally, of course, you would define more meaningful, specific rules that make sense for the package in question. 
In almost all cases that would involve rules like the ones mentioned above for the Prerequisite Rules section AND at least one rule in the Applicability Rules section that would do a version check either on a file or a registry value.  For example, something like the "File Version with Registry Value" rule that says  "look in the registry to find the path to a certain file, then check the version on that file and make sure it is LESS THAN the version I am trying to install with this package."  Without that file version check rule in the Applicability Rules section, you might overwrite the same or later version of the software, and typically that is not ideal. 
Also, ideally, you'd have the exact same type of version check rule in the Installed Rules section, except instead of LESS THAN you would set that rule to EQUAL TO.  That way it can properly report back to WSUS the status of the update for that package.

----------------------
Another, much weirder/rarer reason why I have seen an unexpected "Not Applicable" result is when the target machine is not pointed properly to the WSUS server.  If the target machine doesn't not have the group policy to point to WSUS defined at all or if it is pointed to the wrong WSUS server or the wrong port for the WSUS server, when you try to deploy a 3rd party update to it it will say it is Not Applicable.   I know that doesn't make a lot of sense since you would naturally assume that it would give more of an "I couldn't find that update!" type of error ... but no, it just returns Not Applicable even if that isn't the logical error message for that condition.

What an awesome response! Thank you kellytice , I will give this a go and let you know if I am successful or not.

What an awesome response! Thank you kellytice , I will give this a go and let you know if I am successful or not.