Good-bye SharepointApplied, welcome SharepointResourceCenter

Sharepoint Applied blog has now been officially discontinued.

Please visit my new site: Sharepoint Resource Center. It’s a brand new site based on a slightly different concept (compared to a blog) – see for yourself:

Sharepoint Resource Center

SharepointResourceCenterFrontPAge

...Your gateway to all things Sharepoint...

See you there🙂

Greg

The easiest way to decode SharePoint GUIDs

______________________________________________________________________________
This blog has been discontinued. Please visit my new site based on a completely different concept:
Sharepoint Resource Center

SharepointResourceCenterFrontPAge
…Your gateway to all things Sharepoint…

______________________________________________________________________________

Ever had to parse a list’s GUID (e.g. when porting an SPD workflow) and found yourself copying the URL string from your browser and applying the decoding rules one by one?

Take your decoded GUID (%7B52CC32C3%2D977A%2D405C%2DBD45%2D71F1D60CCC2F%7D), replace %7B with “ { “ , replace A%2D with “ – “
,  replace %7D with “ } “    and so on… Slow, painful and really not the best way to spend your time.

Is there an easier way, sure there is – Google Chrome to the rescue!! Fire up the super-fast browser, navigate to your list/library, click on the View drop down box and choose “Modify this view

image

The address bar will now display your nicely-formatted GUID. As an added bonus you’ll get the current view’s GUID as well. Nice.

image

URL in Chrome

https://testsite/Finance/_layouts/ViewEdit.aspx?List={52CC32C3-977A-405C-BD45-71F1D60CCC2F}&View={03A7E970-D963-491A-9702-BA1A73AC027F}

URL in IE

https://testsite/Finance/_layouts/ViewEdit.aspx?List=%7B52CC32C3%2D977A%2D405C%2DBD45%2D71F1D60CCC2F%7D&View=%7B03A7E970%2DD963%2D491A%2D9702%2DBA1A73AC027F%7D&

Note:

Alternatively, you can use one of the few URL decoders available such as  http://meyerweb.com/eric/tools/dencoder/ or http://www.albionresearch.com/misc/urlencode.php

Customise SharePoint 2010 New Item form in InfoPath 2010

______________________________________________________________________________
This blog has been discontinued. Please visit my new site based on a completely different concept:
Sharepoint Resource Center

SharepointResourceCenterFrontPAge
…Your gateway to all things Sharepoint…

______________________________________________________________________________

Now that SharePoint 2010 Beta has been released I figured it’s a good time to get back to blogging. I’m not sure if I can commit to writing regular longer posts so, for the time being, I will try to post short notes and, hopefully, build on that.

I installed SharePoint 2010 yesterday and I’ve just had a brief 30-mins play with it.

One thing that immediately got me excited is the ability to customise list item forms using InfoPath. What a relief!! I use customised forms all the time – however, customising forms in SPD can be very cumbersome and time consuming.

No more so with SharePoint 2010.

1) Navigate to your list, click on the Custom Commands tab

image

2) Click Customize form. This launches InfoPath 2010 and loads the content type for the list

image

image

3) The standard task form looks quite nice (notice the new “Predecessors” field). However, I wanted to spice it up a bit. Using the familiar InfoPath controls I added a few icons, move fields around (drag and drop – so much easier than using SPD), and added 2 links.

4) I published the form by switching to the File tab and choosing the “Publish your form” option.

image

5) I now navigate to my list, click “New Task” and – Voila! my new customised form appears. How cool is that! All done in around 10 minutes!!

image

I’ve noticed a few issues with the looks of the published form (one of my links is not underlined, the red asterisk in the Description field is misplaced) but, given the advantages of the new approach to editing item forms, I can’t really complain.

Copy Sharepoint SPD workflows in a few minutes

______________________________________________________________________________
This blog has been discontinued. Please visit my new site based on a completely different concept:
Sharepoint Resource Center

SharepointResourceCenterFrontPAge
…Your gateway to all things Sharepoint…

______________________________________________________________________________

Summary: How to copy even a large elaborate workflow in a few minutes without having to update each workflow lookup manually.

Copying basic workflows:

Quite often I need to copy a workflow to another site or site collection (e.g. when provisioning an intranet portal for another client). I usually use the method described here. It basically boils down to a few simple steps:

1) Open the target list/library in SPD, click New>Workflow.
Note: Obviously, all columns used in the source list or library must be present in the target one, also internal column names must match.

2) In the new workflow create 1 step that includes 1 condition and 1 action (e.g. If [field] equals 1, “Set field in current item” to 2).  This step creates the .xoml and .xoml.rules files needed to migrate our source workflow.

3) Open the original source workflow in SPD, open the .xoml file as XML (Right-click > Open as .XML) and copy its contents.

4) Open the target workflow in SPD, open the target .xoml file as XML, replace the content with the content copied in step 3.

5) Do the same for the .xoml.rules file.

Problem:

Normally after saving the files and opening the target workflow you will notice your workflow lookups display GUIDs rather than, as you would expect.  fields, columns and parameters (see screenshot below). This is down to the fact that your .xoml and .rules files reference columns and lists used in the source workflow – if your target workflow is in a different site or site collection these will, obviously, not be recognized and, therefore, are displayed as GUIDs.

image

Old Solution:

Luckily, SPD is smart enough to re-map the workflow to the lists and columns in the current site. All you need to do is click on the GUID and press the “Add Lookup button” – you will see that SPD automatically finds the right list and field:

image

Pressing OK will update the field.

image

Now, this is all fine for a simple workflow – you just click and fix a few lookups and off you go. What if your workflow is a longer more elaborate one – containing many steps and even more lookups, especially ones looking up values in other lists? Suddenly, the above approach becomes quite a cumbersome one.

New Solution:

What I’ve been doing when dealing with longer workflows:

1) Follow the steps outline in the beginning of the post so you end up with .xoml and .xoml.rules files copied from your source workflow.

2) Make note of all the lists used in your source workflow, note their GUIDs. Do the same for the lists used in the target workflow.

TIP: You can use Sharepoint Manager 2007 to easily get the lists GUIDs

3) Open your new workflow in SPD, open the .xoml and .xoml.rules files as XML and replace the source GUIDs with the target ones.

That’s it – if you open your workflow now you’ll see all lookups display correctly and you no longer need to click through them all to have them updated.

Gotcha:

I’ve been happily using the above approach for the last year or so. However, today I ran into an issue that didn’t really make much sense.

I noticed that something funny happened if my workflow used the “Create List Item” action” (I guess the same will be true for “Update List Item” and “Copy List Item” actions).

image

image

You can see in the above screenshots  that all lookups are displayed correctly. However, when I click on the “Tasks” lookup (first screen) to open the Create New List Item dialog box the List value was not populated (even though it’s shown properly in the first screen). Selecting the Tasks list from the drop-down menu had the effect of creating a new action – all the previously defined fields (Description, New Employee, Assigned to) disappeared and had to be put back in manually:

image

This was a major issue as I had over 20 steps using the “Create New List Item” action. I obviously didn’t like the idea of re-creating each of them manually. I opened the .xoml and .xoml.rules files and looked through the code, re-created the workflow in different sites a few times and tested all I could think of. I still couldn’t figure out what the problem is. Finally I spotted the culprit.

Solution:

Turns out the lists GUIDs I pasted into the workflow’s .xoml files were in lower case. SPD was happy with that for all lookup fields. However, lower case seems to trip up the Create New List item action (and possibly other related actions – e.g. Copy List Item).

The moment I changed my GUIDs to upper case (e.g. from fabe5a1-c8d0-4c72-8a66-46c6917abdb5 to 1FABE5A1-C8D0-4C72-8A66-46C6917ABDB5) things magically started to work fine – all field lookups and references mapped properly, no actions need updating. Bingo, I can now copy even large elaborate workflows in a few minutes!

List templates gallery permissions and governance tip

______________________________________________________________________________
This blog has been discontinued. Please visit my new site based on a completely different concept:
Sharepoint Resource Center

SharepointResourceCenterFrontPAge
…Your gateway to all things Sharepoint…

______________________________________________________________________________

Scenario:

A list/library is saved as template. However, users with design permissions cannot see the new template when navigating to sites’ “Create” page (_layouts/create.aspx).

Cause:

Permissions to the List Templates Gallery list (_catalogs/lt/) have been changed – users no longer have Read permissions to the list.

By default members of the Intranet Members group have contribute permissions to the list. If default settings were changed make sure users have at least Read permissions if you want them to be able to create new libraries/lists based on your custom templates.

Governance tip:

The default permissions for the List Templates Gallery are probably fine in most scenarios. However, if you would like to make sure your custom templates do not get “accidently” deleted or modified (somehow there’s always a user or two who likes poking around checking what he can/cannot do) consider doing one of the following:

1) Create a custom permission level and change the permissions on the list to prevent accidental deletes.
One of the first thing I do in new SharePoint deployments is create a new permission level – “Contribute – no delete” by copying the Contribute permission level and deselecting the “Delete item” list permission.

2) Set permission to “Read” on individual templates.
The default “All Templates” view of the List Template Gallery doesn’t show items drop-down menu. Clicking on a template’s name downloads the .stp file rather than, as you would expect, taking you to the DispForm.aspx page for the template where you could access the “Manage permissions” link. Change the default view (or create a new one) and add the “Name (linked to document with edit menu) “ column – you will now be able to set permissions for individual templates

3) Notifications, version history etc.

The List Templates Gallery is a regular SharePoint list. You can, therefore, use Alerts, version history and content approval to make sure you stay in control of changes made to your list templates.

Prevent users from seeing members of other site collections

______________________________________________________________________________
This blog has been discontinued. Please visit my new site based on a completely different concept:
Sharepoint Resource Center

SharepointResourceCenterFrontPAge
…Your gateway to all things Sharepoint…

______________________________________________________________________________

Scenario:

A user decides to give his colleague access to a document. He clicks the Add Users button to select his colleague, clicks the address book icon and types in John in the Select people and groups dialog box. On clicking the search icon he’s presented with a list of 50 different John’s – of which only 3 actually work for his company. The user is confused, talks to his manager, manager talks to his hosting provider – “If I can see other companies’ users they can see mine. Outrageous… and in direct violation of the Data Protection Act. “. What ensues is plenty of some embarrassing explaining to do…

Cause:

The people picker gets all users from the Active Directory where the WSS farm is deployed. By default no filters are applied when users search for people using the  “Select People and Groups” dialog box. In an environment where there are multiple site collection the search box will display users from the whole Active Directory rather than, as you would expect, users from the site collection only.

This behaviour can not only be confusing for end users but can present a serious privacy issue in hosted environments where every site collection is used by a different company and employee information should not be revealed to unauthorised users (those belonging to other site collections/companies). You don’t want end users to be able to search the entire Active Directory

Solution:

Stsadm peoplepicker-onlysearchwithinsitecollection parameter

“The command below will set the people picker so it displays only users that are already added to the site collection. This prevents anyone from using the People Picker to browse a different user directory” [quote from the MS article]

stsadm -o setproperty -propertyname peoplepicker-onlysearchwithinsitecollection -propertyvalue yes -url http://<defualtzone.sitecollection.url>

For full syntax check the following MS article: Peoplepicker-onlysearchwithinsitecollection: Stsadm property

Gotcha

Ok, so the above command is mentioned in quite a few blogs – you could be easily forgiven to just run the command, check your People Picker see results are now trimmed to users from your site collection only and forget about the whole thing. There is one significant caveat to be aware of though – a small, easy to miss, note in the MS article mentioned above says:

“Users can search Active Directory using a fully qualified logon name, regardless of this property setting.”

WTF? Turns out even though users will no longer be able to use the People Picker to search for users outside their own site collection when searching by name they will still be able to snoop around if they use a fully qualified logon name (domainname\username). See the table in this article for the full list of name formats that will still return results from outside of the site collection

Solution:

Microsoft now offers a hotfix to address the issue – described in the following MS article: The Check Names function does not honor the Peoplepicker-onlysearchwithinsitecollection setting in Windows SharePoint Services 3.0

The hotfix will truly lock people picker down – even searches using a fully qualified logon names will not return results from outside of the site collection.

There is a small price to pay though – you will no longer be able to add users to the site collection using the GIU (as no users from outside the site collection will be displayed) and will instead have to rely on STSADM (or code).

Other notes:

For some reason the peoplepicker-onlysearchwithinsitecollection parameter would not work for me a few times – it turns out you seem to have to use the full command without abbreviations:
– this command will work:

stsadm -o setproperty -propertyname peoplepicker-onlysearchwithinsitecollection -propertyvalue yes -url http://<defualtzone.sitecollection.url

– this command will sometimes not

Stsadm.exe -o setproperty –pn peoplepicker-onlysearchwithinsitecollection –pv yes –url http://<defualtzone.sitecollection.url

Troubleshooting SharePoint “Service Unavailable” error

______________________________________________________________________________
This blog has been discontinued. Please visit my new site based on a completely different concept:
Sharepoint Resource Center

SharepointResourceCenterFrontPAge
…Your gateway to all things Sharepoint…

______________________________________________________________________________

While playing with backup/restore scenarios I needed to remove the content database for one of my web applications. On re-attaching the database and navigating to the sites hosted in the web application I was greeted by a “Service Unavailable” error. All other web applications and sites worked continued to work fine.

I always find it interesting to follow people’s troubleshooting steps so below I’m listing the ones I took when investigating the issue. You can scroll down to the end of the article if all you’re after is the solution to the issue:)

The following steps were taken to troubleshoot the issue:

1) Checked the status of the database used by the problematic web application (Sharepoint Central Administration > “Manage content Databases” section) – the status was reported as “ready”

2) Checked event logs – found only 1 error related to the problem:

Event ID: 2436
Source WSS search
Category: Gatherer
The start address <sts3s://[site collection address]/contentdbid={84d79b68-13eb-4cd5-b421-6c44c0c69bed}> cannot be crawled.
Context: Application ‘Search index file on the search server’, Catalog ‘Search’
Details:
An unrecognized HTTP status was received. Check that the address can be accessed using Internet Explorer.   (0x80041204)

I could see the gatherer cannot connect to the website to crawl site. This didn’t however, tell me why the connection is refused/non-operational

3) Restarted the web application’s IIS website in IIS manager
– IIS reset was not an option in the middle of the day.

4) Looked through SharePoint logs – no errors found

5) Launched Sharepoint Manager 2007, navigated to the web application – confirmed I can drill down to subsites, lists etc. The sites and content, therefore, were definitely there.

6) As I couldn’t find anything obvious in event logs or sharepoint logs navigated to C:\WINDOWS\system32\LogFiles\HTTPERR folder and looked through httperr.log files.

What is httperr file? I only learned about httperr logs recently when troubleshooting some pesky IIS issue.

Httperr.log is [pasted from MS site] “a new feature in IIS 6.0. If HTTP.sys is unable to write an error to a Web site log because the request did not reach user mode, the error will be entered in Httperr.log. Errors that are written to Httperr.log include the following:

  • 503 errors
  • idle connection time-outs
  • URL parsing errors
  • the last 10 requests to a failed application pool.

If you need some help in decoding the errors logged in the flie you can refer to the following MS article: Error logging in HTTP API which includes a nice description of the different fields and the order of the fields in httperr log files.

Looking through the files I the following two errors getting logged repeatedly

HTTP/1.1 POST /_vti_bin/sitedata.asmx 503 1790625552 Disabled SharePoint+-+90
HTTP/1.1 POST /_vti_bin/sitedata.asmx 503 1370408763 Disabled SharePoint+-+90

So basically attempts to connect to the sitedata.asmx web service resulted in 503 errors (Service Unavailable). I googled IIS 1790625552 and IIS 1370408763 hoping to get some more info but couldn’t find any articles matching the codes.

A bit of searching led me to the following MS article:
503-Service Unavailable (IIS 6.0)

The article lists the different error codes and causes of 503-Service Unavailable IIS errors.

Looking through the error table I found that the “Disabled” word maps to the following cause “The administrator has stopped the application pool.”.

So the line in my httperr log:

HTTP/1.1 POST /_vti_bin/sitedata.asmx 503 1790625552 Disabled SharePoint+-+90

was basically telling me my application pool “Sharepoint – 90” was stopped.

I opened IIS Manager, expanded the Application Pools node and noticed the application pool used for the problematic web application was indeed stopped.

IISAppPool

(notice the little red icon next to my Sharepoint – 90 application pool)

Right clicking on the application pool and choosing “Start” resolved the issue restarted it and suddenly my sites started working fine again.

Follow

Get every new post delivered to your Inbox.