What is syspolicy_purge_history

This job is created by default when an instance of SQL Server 2008 is installed or upgraded to SQL Server 2008.

SQL Server 2008 introduced a new feature called Policy Based Management. A Policy can be something like xp_cmdshell should not be enabled on an instance. When a policy runs it stores the results in MSDB. Over a period of time, this may will cause unnecessary data getting piled up in MSDB. The job syspolicy_purge_history prunes the data older than the the days defined in HistoryRetentionInDays property of Policy Management.

In the above screenshot it is set to 0 which means that the Policy Evaluation History will never be deleted. So on this instance the job is running just like that 

If this job is missing for some reason, it can always be recreated using the below query

EXEC msdb.dbo.sp_syspolicy_create_purge_job

Workspace Invisible in Lotus Notes

Problem

In Lotus Notes 8.x Standard client, you customize a toolbar by adding the Workspace button. When you attempt to click the Workspace toolbar icon, nothing happens. Additionally, if you focus the mouse on any of the tabs listed below, clicking the button does nothing:

- Mail
- Calendar
- Contacts
- ToDo

 

Cause

The issue is seen only in the Notes 8 Standard Configuration. The issue occurs when the focus is currently in a Java based database/view/document or other user interface (in your mail file or contacts).

Resolving the problem

This issue is fixed in 8.5.2 Fix Pack 2 and 8.5.3

Workaround
Change focus to a non-Java based database/view (such as the Home page or a Notes database other than mail) and then click the Workspace icon.

Steps to reproduce issue:
1. In Notes select File > Preferences. Expand the Notes Toolbar section and select Customize.
2. Add the Workspace button/icon to one of your toolbars, such as the Universal toolbar.
3. Select OK to save the changes.
4. Switch to your mail file.
5. Click the Workspace icon on the toolbar. The Workspace does not launch.

ClickOnce Deployment Application Identity

Scenario supported:  Multiple versions of the same application installed to a single machine/user's account. 
 
For example, say you have a version 2.0.0.0 of an application that is your production version, and you publish a new beta version (3.0.0.0) that you want a limited set of users to access, but those same users need to be able to run both production and beta side by side through ClickOnce on their machines (perhaps for feature comparison testing).

The first step is that you will need to have different deployment manifests for the multiple versions you want a single user to run. You direct the user to launch from each URL to the different deployment manifests and they will get a separate installation on their machine... or will they? The answer depends on a hidden aspect of the ClickOnce runtime regarding what the runtime considers a unique identity for an installed application.

ClickOnce actually install an application on a client machine, it downloads and caches the deployment manifest, the application manifest, and all of the application files. Those manifests have to be signed by a publisher certificate that is cryptographically unique. Additionally, the installed application has a product name that gets embedded in the deployment manifest.

You might be tempted, as I was, to think that a unique product name, combined with a separate deployment manifest would be sufficient to make the client machine treat those installs as separate and distinct (such as setting the product names to "MyApp" and "MyApp - Beta"). Unfortunately you would be wrong, as I was.

There is actually a separate piece of information that the ClickOnce runtime uses to distinguish one application from another - the application identity is set by an identity set for the deployment manifest itself. This identity is normally created by Visual Studio when publishing and is set to the deployment manifest name (i.e. WindowsApplication1.application). You do not have control from Visual Studio to set this to anything else. Through the mageui.exe SDK tool, or better yet my Manifest Manager Utility included with the patterns and practices guidance, you can set this application identity to any string that you like to uniquely identify multiple published versions of a single application.

So to address the scenario presented earlier, you can simply set the application identity to MyApp for one version and MyApp-Beta for the other version, and you will be able to side-by-side install those two copies of the app on the same machine.

I came across this video illustration, really helpful
https://robindotnet.wordpress.com/2009/04/22/clickonce-installing-multiple-versions-concurrently/