New Post: Steps to take if PS script test yields no results in either view

I experienced this as well on my first tries at the PowerShell script. tl;dr: try commenting out the line for 'LoadAssemblies' in the PowerShell script if your host machine has SQL Server 2012 client tools.

After adding write-host and traps to figure out the error, the exception occurred on the line:

(line 162 as of Release 4.1.1)
Invoke-PolicyEvaluation -Policy $Policy -TargetServerName $ServerName -AdHocPolicyEvaluationMode $EvalMode -OutputXML > $OutputFile

Exception is:
'Value cannot be null. Parameter name: policy'

Stumbled upon this write up on the web (https://social.technet.microsoft.com/Forums/scriptcenter/en-US/0573fc94-3f31-4718-a683-4b7091fe16b2/invokepolicyevaluation-fails-with-value-cannot-be-null-parameter-name-policy?forum=sqlsmoanddmo) which appears to confirm from a Microsoft technician that the null parameter is happening within the 'Invoke-PolicyEvaluation' cmdlet. At least for a certain version of the dll. The post describes re-ordering an environment variable to prefer the SQL Server 2014 (\120) tools.

In my environment - a tools server - Windows Server 2008 + SQL Server 2012, the 2014 tools aren't yet installed. As an experiment, I commented out the loading of custom assemblies since EPM 3.0 had been working fine and doesn't include such a step. This did the trick:

(line 110 as of Release 4.1.1)
#LoadAssemblies

The environment is an inplace upgrade from Server 2008R2 to Server 2012, which I would typically avoid in favor of a clean install. That or some combination of the Server 2008 r2 patch level might be why this is uncommon.

Not sure the ramifications of not loading assemblies for other environments, but in this case, all the required funcationality appears to be present because of the load of the 'sqlps' module (?)