Failed to open a connection to the Nintex Workflow configuration database

Here we go with another new issue and easy resolutions & workarounds…

This time, the issue was with Nintex workflows at the time of activating a site collection feature. Let me describe the details in step by step so that it will be easy recognize as well as understand…

Problem Description:

Problem activating Site Feature. While activating the ‘Nintex workflow 2010’ at the site collection level, we faced the following error message:

Error Message:

An unexpected error has occurred.

Troubleshoot issues with Microsoft SharePoint Foundation.

Correlation ID: XXXXX

Troubleshooting Steps:

1)    Most imp regarding any exceptions: SharePoint logs (\14\logs)-specifically if we face “unexpected error”

2)    Windows event logs

3)    If we have a correlation id then it’s very easy to find out the exact error message

After reviewing the SP logs, this is what I found:

Exception was thrown while ensuring dependencies met for feature 'NintexWorkflow' (id: 0561d315-d5db-4736-929e-26da142812c5): Nintex.Workflow.NWFeatureActivatingException: Nintex.Workflow.NW2007DatabaseConnectionException: Failed to open a connection to the Nintex Workflow configuration database. ---> System.Data.SqlClient.SqlException: Cannot open database "NW2007WFDB" requested by the login. The login failed.  Login failed for user 'Contoso\Administrator'. 

What we need to target first in such conditions:

1.    What exactly the app pool identity is used by that web application? Does it have sufficient rights/not?

2.    The Nintex database has a role called WSS_Content_Application_Pools. This is the group that we need to add the app pool identity to

·         SQL SERVER

·         SharePoint_Config

·         Security

·         Users

·         The account which is running the app pool of the web application

·         Right Click-Properties

·         General

·         Database role membership

Resolution:

I have added this group named as WSS_Content_Application_Pools to the APP POOL identity and that it. It worked and issue has been successfully resolved…

If you have any queries/questions regarding the above mentioned information then please let me know.

I would be more than happy to help you as well as resolves your issues…

Thank you.

Customizing the SharePoint 2013 Developer Dashboard using custom scripts

Wow Stefan Gobner has shared a wonderful article on Customising Dev Dash in 2013.

In SharePoint 2013 Dev dash has helped the admins to help troubleshoot a lot of performance issues .
 The Developer Dashboard can now be extended by injecting custom JavaScript code into the developer dashboard window.

Two steps are necessary to achieve this:

1.Custom JavaScript code, which interacts with the developer dashboard DOM, has to be added to a script file that can be accessed from the Developer Dashboard page. E.g. by placing the script file into the _layouts/15 directory.

2.The custom script file(s) have to be registered to be loaded into the Developer Dashboard page.
Below is a short example, which hides the ULS tab in the Developer Dashboard. This example also shows how to use jquery within the Developer Dashboard.

Create the custom logic in a script file

Create a "hideULSTab.js" inside the layouts/15 directory (program files\common files\microsoft shared\web server extensions\15\template\layouts) and add the following script code to it:

// register a code block that runs after the page is loaded
$(document).ready(function()
{
   // iterate over all tabs (identified by CSS class "ms-dd-Tab")
   $('.ms-dd-Tab').each(function(index, para)
   {
      // look for the tab which has "ULS" title
      if ($(para).text().indexOf("ULS") !== -1)
      {
         // hide the title
         $(para).hide();
      }
   });
});

Register the script files with the Developer Dashboard

Our custom script code requires the jquery library – so we have to register two script files with the developer dashboard. That can be done using the following powershell commands:

$contentSvc = ([Microsoft.SharePoint.Administration.SPWebService]::ContentService)
$DevDashboardSettings = $contentSvc.DeveloperDashboardSettings
$DevDashboardSettings.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On

$DevDashboardSettings.userscripts.Add("http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.9.0.min.js")
$DevDashboardSettings.userscripts.Add("/_layouts/15/hideULSTab.js")

$DevDashboardSettings.Update()

As you can see we are registering two different script files: first the jquery library from an external site and second the script file we created earlier.

The powershell script will also enable the Developer Dashboard by setting the DisplayLevel to On.

http://blogs.technet.com/b/stefan_gossner/archive/2013/01/23/customizing-the-sharepoint-2013-developer-dashboard-using-custom-scripts.aspx

How to transfer a site collection from one database to another-SharePoint 2010

Guys- Few days back, I worked on one issue and would like share the experiences so that you can resolve it if you come across the same.

Problem Description:

We had two requirements:

1.   Stop creating site collections in existing databases

2.   Transfer some site collections from existing databases to new databases.

Let’s talk about the first scenario:

Stop creating site collections in existing databases

If you search in Google then you will get tons of results from many blogs/websites/forums/TechNet etc. Everybody is mentioning about ‘making the database offline’-let me tell you it’s very easy but I would recommend you that please don’t use this approach.

Here is the best approach that will be preferable to use across any conditions.

When you will open content database section in reference to any web application section then you will see following highlights:

·         Name of the database

·         Number of site collections exist

·         Maximum number of site collections

·         Minimum number of site collections

So yes-coming back to the main point…As we can see ‘how many site collections are currently holding by this database’ then we can restrict the entry by making proper changes in “maximum & minimum number of site collections”

That’s it-once you do this then you have applied the barrier to that DB and now its deadlocked. When you will create any new site collection now then it will go to new database.

CLEAN & SIMPLE J isn’t it?

Transfer some site collections from existing databases to new databases

Now coming back to second point, how to transfer the site collections from one DB to another. Many of us will give a thought (rocket serving thought J )that yes, it can be done by backup/restore, export/import!!!

If you are thinking like this then let me correct you that Microsoft has introduced some enhancements in the Power shell and it’s a point of one execution command only.  Let me refer you that TechNet article that reflects the same.

Power shell Command:

Move-SPSite http://servername/sites/sitename -DestinationDatabase ContentDb2

Note: This example moves the site collection http://servername/sites/sitename to the content database ContentDb2.

That’s it-Requirements fulfilled and we are done with this article J

If you have any queries/questions regarding the above mentioned information then please let me know.

I would be more than happy to help you as well as resolves your issues J

Reference: http://technet.microsoft.com/en-us/library/ff607915.aspx

Product applies to:

SharePoint Server 2010

error 503 and unable to access the MOSS site

Problem Description:
Gets error 503 and unable to access the MOSS site anymore after installing a German language pack

Error Message:

503, service is unavailable

Farm Configuration:

Product / Version / Bit: SP2010/14.0.6335.0000/X64
Operating System / Service Pack/Bit: Win 2k8 R2 /SP2/X64
Farm Configuration: 3 WFE
Hardware (Physical/virtual): Hyper-V
Database Used: SQL server 2008 R2

Troubleshooting Done:

1.   Tried accessing all the sites, just to make sure that the problem is restricted to one site or across the whole farm

2.   Reviewed SharePoint logs

3.   Checked event logs

4.   Checked the connectivity between SQL and SharePoint

5.   Checked the application pools are running or not

Cause:

§  Found out that the applications pools are all stopped and that’s why the sites not running.

§  It looks like when the language pack is installed and then the issue started happening.

Resolution:

§  Started the application pool one by one and tried accessing the sites

§  All sites are accessible now without any issues…

Additional Notes:

§  Noticed that one of the content DB (WSS_content_ABC) shows that a few sites are not upgraded to SharePoint 2010.

§  Detached the content Database and attached it back to the same web application, just to make sure that the DB gets upgraded.

Product Applies To:

§  SharePoint 2010

§  SharePoint 2007

If you have any queries/questions then please let me know, thank you.

What are the accounts used in SharePoint Foundation 2010 for a least privileged configuration

In Many Organization while Implementing  SharePoint 2010 . the first question which may arise is What are the account we need to create and what are the permission levels it should have . I have tried my best to collate the things together and text it in my Blog .


The setup account: This is the account with which the useris logged that runs the setup. This account must be a local administrator on all systems where SharePoint Foundation 2010 setup is run.

Post-Setup Configuration Run-As user: This is the user that runs the PSC tool.
This user must also be a local administrator
PSC runs a prerequisites check .
In addition to being a local administrator on all computers running Office Server, this account also has the following requirements on a remote server running SQL Server to be used as part of a SharePoint Foundation 2010 Services farm

Must be a SQL login
Must be a member of the SQL Server Database Creators Role
Must be a member of the SQL Server Security Administrators Role
This account need not be a local administrator on the server running SQL Server

Thisis the only account given explicit rights on SQL. It will give the database access account the SQL privileges it needs because it has the rights to do so.

The database access account: This is the account that is specified to the PSC tool when creating or connecting to a Configuration Database.
This account need not be the same as the PSC Run-As user and it need notbe a local administrator on any computer running Office Server.
It should also not be a local administrator on the SQL server, and doesnot require any SQL permissions in advance of creating a configuration database. Many of us refer to this as the “farm admin” account, but thisis misleading. The user that accesses the Central Admin Web pages to perform farm administrative activities is the farm admin account.

Central Admin App Pool ID:This account is “automatically” configured by the PSC tool to be the same account as the database access account that is stipulated to the PSC tool when creating a configuration database. This account and the SPTimer account constitute one exception to separate accounts being usedfor all account types.

The SPTimer account: As with the Central Admin App Pool ID, this account is “automatically” configured by the PSC tool to be the same account as the database accessaccount that is stipulated to the PSC tool when creating a configuration database.

The Farm Admin account: As mentioned earlier, this is the user that accesses the Central Admin Web pages to perform farm administrative functions.
This account can create Web applications, site collections, SSPs, configure Search, IFSS, Profile Imports, assigning permissions, and so on.