Monday, June 30, 2014

Recovering Workflow History after 60 Days

I really like this article and helped out resolving the issue:

Reference Site: Recovering Workflow History After 60 Days

Workflow history is one of two things to SharePoint users. I suspect for the majority, they aren't even aware of it, and don't have any need for it. For a small minority, they are fully aware of it for one important reason – compliance. Workflows are nearly always used as part of a larger business process, and often these business processes require auditing to ensure compliance with whatever industry standard the business operates with. When SharePoint workflows are used, workflow history is usually seized upon by users as being an easy way to audit compliance. After all, it's easy to get at isn't it?
Certainly while the workflow is in progress, and for a couple of months afterwards it is. But what happens when the end of year audit arrives, and the auditor goes to look at the history for a workflow completed 11 months ago? Disaster – it's not there! There must have been many a frantic phone call between panicking compliance officers and frustrated IT staff along the lines of this:
  • [Compliance officer] "My workflow history has been deleted! The auditor is going to fail us! Where has it gone?"
  • [IT support] (probably after Googling "Workflow history deleted") "This is by design. SharePoint deletes workflow history after 60 days"
  • [Compliance officer] "WHAT?! Nobody told me that! Can you recover it?"
  • [IT support] "We can, we'll just need turn off the timer job and then restore the entire SharePoint farm for each month in question."
  • [Compliance officer] "How long will that take?"
  • [IT support] "Hmmm…."
Both parties are at fault here. The compliance officer for writing a feature of SharePoint into the compliance process without knowing how it worked, and IT for not explaining the 60 day "deletion" actually happens. The good news is though, workflow history isn't deleted, all we need to do is make it easier to find.

So Where Is Workflow History after 60 days?

Put simply, it's in the same place as it's always been. There's a hidden list in every SharePoint site with the workflow feature activated called "workflow history" and it's under lists, so pointing your browser at http://[sitename]/[subweb]/lists/workflow%20history/ will show you this list. It's not pretty, and certainly not usable by an end user in its default view, but it is the same content that was available from the item that the original workflow ran on. All that happens after a workflow has been closed for 60 days is that the relationship links between the item (list item or document) and the workflow history are removed from the database by a timer job. The reason this is done is that a workflow can consist of many individual steps, each of which gets recorded in the history list. Maintaining those links in the database for every workflow that ever runs in a site slows performance down. So Microsoft implemented a clean-up job to remove the links, making it appear from the item that the workflow history is gone. It's possible to disable the timer job, but this has to be done at the application level, will kill performance in the long term, and doesn't help you get back the "missing" workflow history.

Making Workflow History Usable Again

Knowing that all Workflow History is available in a list, all we need to do is link it back to the original item using a calculated column and a view. The basic steps are:
  • Create a view of the workflow history list that uses the filtered ID to present the history of a particular workflow in a recognisable format.
  • Create a new calculated column in the list or library that is associated with the workflow.
  • Write a formula in the calculated column that inserts the item/document ID into a link that can be passed to a view of the workflow history list.
Once we've completed these steps, any user who can open the item will be able to see the new link to the workflow history and view that. Now for the nitty gritty:

Create views of the Workflow History List

  1. Open the workflow history list at http://appname/subweb/workflow%20history/
  2. Create a new shared view; you'll need one for each list that has a workflow associated with it – if there's only one, call the new view "audit view", otherwise "workflow name – audit view" or something similar.
  3. You'll need to identify the List or Library ID (GUID) – You can use the full history list for this.
  4. As a minimum, add the following columns to the view:
    Date Occurred
    User ID
    Event Type
    Outcome
    Description
  5. Sort the view by "Date Occurred"
  6. Filter the view by "List ID" (List ID is equal to GUID – include the braces)
  7. Group by "Primary Item ID", then by "Workflow History Parent Instance"
  8. Save the view, try it out – add any other customisations your audit process may need.
At this point the view will return all history for a particular list, in the next steps we'll create a link that opens and filters workflow history for a particular item.

Create the calculated column for a list/library

  1. Within the list that is associated with the workflow, add a new calculated column. Do this for each list from which you need to see the workflow history.
  2. Enter the following formula, replacing appname and subweb with the address of your site, and viewname with the view you just created:
    =CONCATENATE("http://appname/subweb/Lists/Workflow%20History/viewname.aspx?&FilterField1=Item&FilterValue1=",ID)
  3. Add this column to the default view, or create an "auditor's view" of the list, containing this column and any other pertinent information.
  4. Now users can click on the link created dynamically by this column to return a filtered view of the workflow history, containing audit information on each step in every workflow that ran for this list item.

Make the workflow history easier to read

Out of the box, the workflow history contains a lot of GUIDs instead of real names (I suppose this is where deleting all those links made sense to Microsoft). To make it more human legible, you can add further calculated columns to the workflow history list to turn some of those column values back into real names. A good example is the workflow name, which is represented by "workflow association ID"
  1. Add a new calculated column called "Workflow name" to the workflow history list.
  2. Use the following formula:
    =IF([Workflow Association ID]="{GUID of particular workflow}", "Name of particular workflow",IF([Workflow Association ID]="{GUID of another particular workflow}", "Name of another particular workflow"))
  3. Now save and add this column to your workflow audit views.
That's all. It's clearly not as straightforward as being able to use the OOTB workflow history from the item, but if it means you can still access the same information anytime without harming the performance of the database, it's definitely worth doing! If you know you're going to need workflow history for multiple sites, it's probably worth adding the views at least to the site template before the sites are created, and you could even add the columns to the default libraries with some placeholder values to aid deployment.

Friday, May 17, 2013

SharePoint Reporting : PerformancePoint Services Dashboard using Analysis Services

Part - 1

 Part - 2 


Part - 3


Microsoft Analysis Services - Basic Presentations (Cube,Dimensions,Measures,Facts and So on)

Analysis Services - 01 Prerequisite Guide


Analysis Services - 02 Data Source Creation


Analysis Services - 03 Data Source Views


Analysis Services - 04 Cube Creation


Analysis Services - 05 Dimension Fundamentals


Analysis Services - 06 Dimension Hierarchies


Analysis Services - 07 Dimension Attribute Relationships


Analysis Services - 08 Dimension Storage


Analysis Services - 09 Dimension Discretization


Analysis Services - 10 Parent/Child Dimension Hierachies


Analysis Services - 11 Star and Snowflake Schemas

Wednesday, May 8, 2013

Project Server 2010 : Failed to provision site PWA with error: System.NullReferenceException: Object reference not set to an instance of an object.

Problem:


I was trying to take project server 2010 databases from PROD and refresh them in the DEV environment by using 5 database restore process (Reference: Project Server 2010 : Migration or Restore in New Farm) .
When I tried initially, the PWA site was missing the Project Site urls under Server Settings -> Project Sites page. Then, I deleted the SharePoint web application and also deleted the Project Server related 5 DBs manually. I restored the 5 DBs and added the project server content db to the newly created web application. When I tried to Provision the Project Web Application (PWA), it failed and I observed the following 3 error messages in Event Log:
Event Log: Error Log Entry 1
Failed to provision site PWA with error: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.SPSite..ctor(Guid id, SPFarm farm, SPUrlZone zone, SPUserToken userToken)
at Microsoft.SharePoint.SPSite..ctor(Guid id)
at Microsoft.Office.Project.Server.Administration.ProjectSite..ctor(Guid webAppId, Guid siteId, String adminName, Int32 lcid, Boolean needsUpgrade, PsiServiceApplication parent)
at Microsoft.Office.Project.Server.Administration.ProjectSiteCollection.Add(Guid webAppId, Guid siteId, String adminName, Int32 lcid, String PubDBConnString, String VerDBConnString, String WorkDBConnString, String RepDBConnString, Boolean needsUpgrade)
at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)
Event Log Error Entry 2: Provisioning ‘PWA’: Project site object creation failed. Exception ‘System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.SPSite..ctor(Guid id, SPFarm farm, SPUrlZone zone, SPUserToken userToken)
at Microsoft.SharePoint.SPSite..ctor(Guid id)
at Microsoft.Office.Project.Server.Administration.ProjectSite..ctor(Guid webAppId, Guid siteId, String adminName, Int32 lcid, Boolean needsUpgrade, PsiServiceApplication parent)
at Microsoft.Office.Project.Server.Administration.ProjectSiteCollection.Add(Guid webAppId, Guid siteId, String adminName, Int32 lcid, String PubDBConnString, String VerDBConnString, String WorkDBConnString, String RepDBConnString, Boolean needsUpgrade)
at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)’.
Event Log Error Entry 3: ProjectSite not created.
SOLUTION:
Something in the SharePoint config or Project Server Config was corrupted.
After hours of trial, I ran the Project Server Installation wizard and did Repair of the installation. The repair process went successfully. 
After that, I did following:
a. Created Web Application with default root site collection.
b. Ensure that site is up and working fine.
c. Go to manage content databases, remove the content database for the above created web application.
d. Restored all the 5 databases in the database server.
e. Attached the project server content database(s) to the web application using the STSADM command (not thru UI). After attaching, if we go to View Site Collections option from Central Admin, we should be able to see PWA site collection for the above created web application.
f. Navigated to Project Server Service Application and created a new Project Web Application by pointing to restored Archive, Published, Reporting, Draft databases.
g. Project Web Application provisioning took sometime and provisioned successfully.
h. When I opened the PWA site, the site came up fine but faced few minor issues which I resolved with the help of following posts:

Finally happy with the output :)

Note: The above is just my experience. Please ensure you fully understand and leverage from my experience for your needs to avoid any further issues.

Wednesday, May 1, 2013

Project Server 2010 : PWA Errors and Trouble-shooting

While I was refreshing DEV environment from PROD for Project Server, I ran into many issues.

The following article explained the solution for various of the issues:

MS Project Server 2010 -> PWA Errors & Troubleshooting

Tuesday, April 30, 2013

Project Server 2010 : Common errors when a PWA site is deleted ‘incorrectly’

From last few days, I was working multiple Project Server 2010 installations/migrations.

I ran into many issues and I came across the following blog post which helped me in resolving those issues.

Common errors when a PWA site is deleted ‘incorrectly’


Project Server 2010 : Migration or Restore in New Farm

Currently, I am working on Project Server 2010 restoring the PROD copy in DEV/TST environment.

As we know, there are 5 databases related to Project Server 2010 which we need to use for migration/restoring in new farm.

There are many approaches for this operation which are explained well in the following blog posts from Andrew:

Project Server 2010 Database Restore (Part I)

Project Server 2010 Database Restore (Part II)