SharePoint deploy timer job stuck “Deploying”

A developer on our team was trying to upgrade his solution and asked for my help since the job was showing "Deploying" and he was receiving an error when trying to execute the upgradesolution stsadm command.  The error he received was: 

 

Sharepoint Service Error:  A deployment or retraction is already under way for the solution <solutionname>.wsp, and only one deployment or retraction at a time is supported 

 

I was able to resolve the issue by running the stsadm -o enumdeployments.

 

This gave me a listing of all deployments that were pending on the server.  There were a few and it turned out a failed deployment from another developer was blocking this new deployment.

 

The enumdeployments output gives you the GUID ID for each pending job.  I captured each ID and then ran the following command to clear the jobs:

 

stsadm -o canceldeployment -id <ID>

 

Once complete, verified that no jobs remained by rerunning enumdeployments command.  After that, the original solution upgrade could be completed. 

 

Final note is that if this issue arises, it is not a good practice to repeatedly try stsadm -o execadmsvcjobs.  Sometimes this command is run to force a timer job to run when a -immediate is done on a deployment.  If you don’t want to wait for the timer, use -local and deploy to each SharePoint farm box individually.  The execadmsvcjobs can have unintended consequences.

 

Image View Web Part

I needed to throw together a quick PoC that showed an Image on a SharePoint site which seems like an easy task.  I already had a document library and the easy thing to do would be put the image in the library and link it on an Image Web Part on the specified page.  That would meet the requirement.

 

However, SharePoint solutions being what they are, I know the user community may soon demand more from their images.  So, I created an Image Library which is a special type of document library provided by WSS.  It allows pictures to be viewed as thumbnails as well as in a slide show in a pop-up window which could be nice for people that do presentations from the site which is an intended use.

 

Next, I needed to create the Image Web Part, but I wanted to give the user to change the image in the part without popping open a slide show.  During this exercise, I first learned that the Filter web parts did not seem to work for this scenario.  I may have been missing an intermediate step, but a drop down filter did not appear to be an option. 

 

The following attempt was to connect a list view web part of the image library to the image web part.  This didn’t work either since the image library does not have a URL field.  I could have created the field and populated it through an event or workflow (not sure if calculated field would work here), but decided that was not the way to go either.

 

In the end, I used a link list web part to connect to the image web part.  In this solution, I will still need to create an event or workflow that adds the image link to the web part to save the end user from having to create the image and then creating the URL link.  However, the connection was immediately available and worked as intended.  The only drawback was that I could not have an image selected by default so I will need to be sure the link to the page contains a query parameter for the default selection (inferring that an image must be provisioned with the library).

 

My takeaway was that yet again something that seems to be simple may not be as quick to implement and knowing your web part limitations up front is important.

Houston SharePoint User Group meeting tonight

If you are in Houston and work on SharePoint, you should want to attend the H-SPUG meeting tonight (Wednesday, September 16th).  The event has split into two presentations with a General session and a Technical session.  Tonight you will find me at the Technical session related to site branding.  The General session is related to security.  As always there will be door prizes, and food is provided by Intellinet at the meeting.  After the meeting, there is a social hosted by Volt Technical Resources (usually at the Rajun Cajun at Westheimer and Gessner).

 

You can register for the meeting here:

http://sharepointusergroup.corasworks.net/HOU/Default.aspx

 

You can also join the LinkedIn group here:

http://www.linkedin.com/groups?gid=33609

 

Hope to see you there.  Also, stay tuned for the November and December meeting announcements.  The December meeting is going to be a bigger event with SharePoint MVP’s and will be at the Norris Conference Center.

Troubleshooting Tips for SharePoint

Many of my posts are results of issues faced as I’ve worked with SharePoint.  As a consultant, we are often faced with issues that are not well documented even now after multiple years of release.  So, I thought I’d offer my quick list of steps that I use when debugging SharePoint problems.

 

1. Check the Windows Event Log – Often, the windows application event log will have problems that are recurring in your SharePoint farm.  You can be proactive and find the root cause of the issues being reported before a user begins to notice unexpected behavior.  I generally use Bing/Google to search for KB articles that may recommend fixes.  Also, eventid.net is a good resource to look up errors and warnings.
2. Enable debugging – Using the web.config to enable page trace information can provide immediate direction to seemingly complex issues.  To enable debugging, make a copy of your web.config just in case.  Then, find the customerrors entry and set to Off.  Next, find CallStack and AllowPageLevelTrace and set both to true.  Finally, set debug in the compilation section to true.  Now, you will have more detailed errors than "Unknown error" on your SharePoint page. 
3. Check the ULS Logs – The ULS logs are cumbersome to use at first because they contain a lot of information.  Remember that you can set the logging level in Central Administration under Operations (or use stsadm -o setlogginglevel).  If you cannot find your log files, they are generally in the 12 HIVE under LOGS, but a custom configuration will likely change this location which is good for disk space reasons.  Once you find the logs, take the steps to create your error, pop open the file, and start reviewing at the bottom working up.  There is a lot of information in these logs and like the Windows event log can be used to perform preventative maintenance as well.
4. Use SharePoint Designer – Sometimes, errors can be quickly found using Designer.  I often discount designer as a purely configuration based tool, but if you have a badly formed New or Edit form, finding the error by the above methods can be difficult.  Opening a New form in Designer one time immediately showed me that the issue was a malformed master page. 
5. Visual Studio Debugger – Attaching the Visual Studio IDE to the w3wp.exe process allows custom code to be debugged.  If you are armed with an informative error from item two above, you can also know exactly where you may want to place a breakpoint.  However, in many environments you may not have VS on the box where you need to debug.  You can use remote debugging though sometimes having DLLs that match the code can be an issue.  Still, debugging code is a tried and true way to pinpoint tricky errors.
6. SPDisposeCheck – Preventative tool.  However, if you have issues with app pool recycles and see a lot of "large number of SPRequest" in your ULS, start investigating custom code using this tool.  I would recommend that all code be run through this tool prior to any deployment to a Farm.
7. Fiddler – Fiddler is useful when you are having authentication issues, strange css behavior, and more.  You can even change HTTP requests on the fly which can be handy if you not only want to pinpoint a problem but uncover the fix at the same time.
8. SharePoint Inspector / SharePoint Manager – These tools allow you to browse the object model side of your SharePoint content.  I haven’t found them as useful lately, but they can let you see a lot of detail quickly if you don’t want to use PowerShell to browse the objects.
9. PowerShell – PowerShell is a great administrative tool and can help implement quick fixes.  Our team uses it to fix security issues and run large updates to items that have to be fixed NOW.  Of course, powershell has a lot of other purposes, but I often use it to fix things rather than find issues which is why I didn’t list it earlier.

Last but not least are the social aspects of troubleshooting-

1. Colleagues – Tap the experience in your close network.  No one knows it all so don’t be ashamed if you have an issue you cannot tackle yourself
2. Bing / Google – Usually, unless you have a direct error to search, web searches can be hit or miss.  However, being a good user of a search engine is a skill that not everyone possesses.  Learn how to form your queries so you can quickly target relevant content.  Also, gravitate towards technet, msdn, blogs, and KBs.  Usually sites like eggheadcafe and expertsexchange are not very helpful.
3. Twitter – Sometimes I Tweet the errors that bug me the most.  I have not had much success probably due to the large amount of content on the tweet stream, but still it makes me feel better shouting out.
4. Microsoft Support – Make sure you timebox your troubleshooting efforts so that you don’t spend so much time that the value of your efforts begins to diminish.  Remember that your time has a cost and that if that cost is excessive, it would be better to cash in that support ticket with Microsoft and get some help.  You will still need to give up some time.  However, if you understand most of the issue, the technicians will set a scope and try to get to the bottom of the issue.  The support is usually built into the Enterprise Agreement (EA) so may as well use it.

Chasing errors can be a very fustrating experience, but knowing your tools and having a plan of attack can minimize much of the angst.  Good luck with your issues and happy error hunting!

Adventures Fixing SharePoint LAYOUTS

Recently, I applied SP2 to our SharePoint farm in DEV, TEST, and PROD.  During this process, we patched SQL 2005 DBMS, SSAS, SSIS, and SSRS instances to SP3.  Then, we applied SharePoint 2007 and WSS 3.0 SP2 (with related language pack updates for both versions as well).  Finally, the June Cumulative updates were also applied.  After this was complete, we expected to see better performance from SSRS reports as well as a fix to a deadlocking issue when custom events were triggerred. 

 

However, the real reason I write today is to address an issue that was discovered after applying the service packs to the DEV environment.  Part of the update process included deploying the most recent version of Nintex to our servers.  Doing this releases new actions which have to be allowed through Central Administration’s interface.  Accessing the relevant link goes to an _layouts folder which produced the following error:

 

Cannot complete this action.

Please try again. at Microsoft.SharePoint.Library.SPRequestInternalClass.OpenWebInternal(String bstrUrl, Guid& pguidID, String& pbstrRequestAccessEmail, UInt32& pwebVersion, String& pbstrServerRelativeUrl, UInt32& pnLanguage, UInt32& pnLocale, String& pbstrDefaultTheme, String& pbstrDefaultThemeCSSUrl, String& pbstrAlternateCSSUrl, String& pbstrCustomizedCssFileList, String& pbstrCustomJSUrl, String& pbstrAlternateHeaderUrl, String& pbstrMasterUrl, String& pbstrCustomMasterUrl, String& pbstrSiteLogoUrl, String& pbstrSiteLogoDescription, Object& pvarUser, Boolean& pvarIsAuditor, Int32& plSiteFlags)
at Microsoft.SharePoint.Library.SPRequest.OpenWebInternal(String bstrUrl, Guid& pguidID, String& pbstrRequestAccessEmail, UInt32& pwebVersion, String& pbstrServerRelativeUrl, UInt32& pnLanguage, UInt32& pnLocale, String& pbstrDefaultTheme, String& pbstrDefaultThemeCSSUrl, String& pbstrAlternateCSSUrl, String& pbstrCustomizedCssFileList, String& pbstrCustomJSUrl, String& pbstrAlternateHeaderUrl, String& pbstrMasterUrl, String& pbstrCustomMasterUrl, String& pbstrSiteLogoUrl, String& pbstrSiteLogoDescription, Object& pvarUser, Boolean& pvarIsAuditor, Int32& plSiteFlags)

Checking this error via Google and Bing yielded only one consistent resolution related to permissions being disconnected from the parent site.  I checked with Nintex related to this issue and, and they attempted to help but soon it was realized that the issue also affected Site Actions->Site Settings pages as well.  So, the problem was larger than just Nintex.

I then checked the ULS errors to see if I could get some more information.  There I found this error (this is not my exact error, but a similar error I found searching the technet forums): 

03/26/2009 10:16:46.18  w3wp.exe (0x1C1C)                        0x1BD8 Windows SharePoint Services    General                        7fd9 Unexpected ERROR: Failed to OpenThreadToken, LastError=1008 

Basically, at this point I hit a roadblock since no meaningful information was apparent.  We had a workaround since our main web application did not have the issue and we could configure Nintex from the site collection.  Also, Central Admin and the SSP were functioning correctly other than the _layouts page issue.  So, the problem was only with Central Admin. I did try to recreate the site twice using psconfig and also by deleting it from IIS and Inetpub and rerunning the Config wizard.  This also did not work.

So, now we found out a new web app’s critical path to success was deployment to Dev and it had the same issue as the Central Admin site.  Also, the solution for this web app relied on several LAYOUT pages that would not function until this issue was resolved. 

Which brings us to the resolution and the part we’ve all been waiting to implement.  A co-worker of mine suggested that we check web.config in the LAYOUTS folder in the 12 Hive.  There was a separate file there which is a rather short file.  I quickly noticed that the web.config file had impersonate=false set.  This was not correct if we were to have Kerberos working properly so I changed it to true.  Suddenly, all web applications that had this issue started to work properly again. 

The lesson learned here is that the problem may indeed lie within a web.config file, but that it may not be the one we are all used to checking.  Be aware of your 12 Hive and Inetpub topology as well as the configuration files that lie within and the issues they can cause if misconfigured.