MOSS-moiselles

I am part of the performance team, and we are responsible for making performance guidelines for our development team. Here is an article which I wrote earlier where I am talking about why you should not have separate JS file for each of the page that you create.

This article talks in great details about the performance implications of having page specific JS files, why they should be avoided and what can be the alternate solution.

Though, I have written this article, I have brought the recommendations or suggestions from other blogs. Wherever any outside blog is referred I have given an external link. You should read these external articles to get complete hold of the context.

Here it goes:

I have spent quite a few hours with our team in discussing  whether you should have a page specific external JS file.

I tried my best to answer most of the questions raised by you guys; however there were great concerns that we are defying our basic best practice of not writing JS code directly into the page.

Why developers are reluctant to accept this to be a best practice followed in industry? I will answer this from directly from one of the book I referred during the preparation of best practices document:

“For developers who have been trained to write modular code (whether in JavaScript or some other programming language), this suggestion of combining everything into a single file or writing it inline seems like a step backward, and indeed it would be bad in your development environment to combine all your JavaScript into a single file. One page might need script1, script2, and script3, while another page needs script1, script3, script4, and script5.”

I have spent a considerable amount of time over the last 2 days in collecting all the statistics and information to make it clear that why we should not be creating a JS file for each of our pages.

This mail is going to be quite a lengthy mail, so those of you who are not interested in reading through rest of the material, here is the conclusion:

“You shouldn’t have a page specific JS file.”

Main reason behind this recommendation: Only 10–20% of the end user response time is spent downloading the HTML document. The other 80–90% is spent downloading all the components in the page.

Let’s begin:

I will start by jotting down all the concerns raised by the team one by one and then will try to explain that why that is actually either evading the best practice or is clearly not a best practice:

- Having external JS file makes your code more readable.

- There is always a tradeoff when you want to follow a best practice.

- I like keeping my files outside the page as it is cleaner.

- Having external JS file is a best practice as written in coding standard document.

- Having external JS file doesn’t hurt server, as server has considerably high configuration and can create and respond to multiple requests at the same time.

- If you don’t want to create external files, why create one for master page also. Keep your code directly into the page as it will be delivered with the request always.

- External JS files helps in caching.

- In case when the page is not getting saved quickly (this is mostly the case with heavy pages e.g. in Cascade, Heatmap and VendorExtranet) we prefer keeping JS in a separate file. This saves a lot of development efforts because we will need to just open the JS and make all the changes.

References:

In this article I will be using references from following 2 sites/blogs and 1 book.

- Yahoo’s performance research team’s article in 6 series.

o Part 1

o Part 2

o Part 3

o Part 4

o Part 5

o Part 6

This is a very interesting series, despite being lengthy. I would rather like you to go through all the 6 links however, not all 6 articles are relevant to the argument in consideration here. For this argument’s sake please refer only articles 1, 2, 4 and 6.

- Google developer blog’s article about round trip time, its impact on web page and how to reduce it. All the recommendation here are mentioned in our coding standards document in one way or the other. For this particular argument I would like you to refer section titled: “Combine external JavaScript”

- A book titled: “High performance web sites – Steve Sounders”. He is from YUI performance team at yahoo. This book gives 14 best practices and it is recommended to go through them all however for this point you will need to go through chapter 1 and chapter 8.

Time to dissect:

Before I start I will answer the most important question and that too in just one word:

Q. Why do we follow best practices?

A: To reduce PLT.

1. Having external JS file makes your code more readable.

How readable is the following code?

var _0xe4f9=["\x48\x65\x6C\x6C\x6F\x20\x57\x6F\x72\x6C\x64\x21","\x0A","\x4F\x4B"];var a=_0xe4f9[0];function alert(_0xda6cx3){alert(_0xda6cx3+_0xe4f9[1]+a);} ;alert(_0xe4f9[2]);

It’s not readable. This is an obfuscated version of a code. Obfuscation is a process followed religiously by all the companies. E.g. All the SP js are obfuscated, JQuery js is obfuscated etc.

Why? When you consider the performance metric, readability does not make an entry. I as a developer will not going to make a code readable at the cost of my PLT.

We do not write code to make it readable.

We write code to achieve certain functionality in a best possible way. While trying to achieve something in a best possible way our code ultimately becomes readable. The problem here is, you start writing your code with this thought in mind that I want to make it readable.

What you need to understand is readability is not the aim, it’s a byproduct.

One argument that comes close to counter this is why then we follow naming conventions? Yes, we follow naming conventions to make our code readable. However, naming conventions are not just to make your code readable but scalable. A developer when opens his own code 10 days after he had last written it will not be able to make sense of its head and foot unless the code is written with proper variable names and commenting.

So think about it this way: writing code with proper naming convention isn’t really a step towards writing your code in the best possible way?

2. There is always a tradeoff when you want to follow a best practice.

There might be in certain cases, but that is not the case with this particular recommendation.

3. I like keeping my files outside the page as it is cleaner.

Read point 1 with replacing word readable with cleaner.

4. Having external JS file is a best practice as endorsed by other companies.

Coding standards doesn’t outlines that you need to have a separate JS file for each page you are writing. On the contrary if you actually open the coding standards document you will notice a note that goes like this:

Note: Though it is mentioned to split scripts into 2, care should be taken to monitor the number of files that are being requested. Combined files are a way to reduce the number of HTTP requests by combining all scripts into a single script (at most 2), and similarly combining all CSS into a single style sheet. Combining files is more challenging when the scripts and style sheets vary from page to page, but making this part of your release process improves response times.

5. Having external JS file doesn’t hurt server, as server has considerably high configuration and can create and respond to multiple requests at the same time.

Server might, but can client handle it?

Its not about the performance of the server but client. By default you client browser’s limit the number of parallel downloads per hostname (in IE its 2). So at most only 2 files will get downloaded at a time. Consider this situation, SP requires multiple JS files for its own functioning. On top of that you are adding multiple requests for your own JS. Does that by any way help in getting the page load faster? On the contrary it in-fact deteriorates page’s performance.

Consider following example, taken from Google developer’s blog:

Here we are downloading 13 different files, and it takes browser 4.46 seconds to download these files.

Consider an alternative design, where you combine all of these files into one:

And suddenly your page request time dropped to 1.87 seconds.

We are downloading the same amount of data, then how the sudden drop from 4.46 to 1.87 seconds? This is because of reduced number of http requests which results reduced RTTs.

6. If you don’t want to create external files, why create one for master page also. Keep your code directly into the page as it will be delivered with the request always.

7. External JS files helps in caching.

On the outset these 2 points might look completely unrelated, however they are not. I will try to explain these 2 points together.

Consider the following scenario taken from “High Performance web sites” book.

This is the case when a user visits http://www.yahoo.com for the first time, with empty cache. Now consider second visit:

Isn’t caching cool?

Now to take advantages of caching, we need to have external JS files. That clearly answers the first question that why you should place your common code into external JS files and not directly onto the page itself.

Now second point: If caching is so cool why not use it for each page?

Table 1. Empty and Full Cache Summary to load http://www.yahoo.com

Now the question: How many users actually view a high traffic site like yahoo with full cache?

The answer of this question is given clearly in part 2 of YUI blog mentioned above. Here, I will mention in brief about the experiment they carried and its answer.

Experiment: From YUI blog: – The performance team at Yahoo! ran an experiment to determine the percentage of users and page views with an empty cache on some of Yahoo!’s most popular pages. We defined the experiment to measure users’ cache behavior related to a new component (an image). For this new image we measured the following statistics each day:

- What percentage of users requested the new image?

- What percentage of page views requested the new image?

Result: Figure 3 shows the percentage of users and page views with an empty cache plotted over each day of the experiment. On the first day of the experiment, no one had these images cached so the empty cache percentage was 100%. As the days passed more users had the images cached, so the percentages dropped until at some point it reached a constant steady state.

Figure: Percentage of Users and Page Views with an Empty Cache

40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache. To my knowledge, there’s no other research that shows this kind of information. It says that even if your assets are optimized for maximum caching, there are a significant number of users that will always have an empty cache. This goes back to the earlier point that reducing the number of HTTP requests has the biggest impact on reducing response time. The percentage of users with an empty cache for different web pages may vary, especially for pages with a high number of active (daily) users. However, we found in our study that regardless of usage patterns, the percentage of page views with an empty cache is always ~20%.

20% empty cache for the page that is among the most active pages on internet. Think how active your page is in MS Corp net? Another point to consider is that cache size is always limited. So with time browser will start removing contents from cache to accommodate newer contents. And if your page is not among the pages which are visited frequently by users it is very much possible that each time user will request that page he will do that so with an empty cache.

8. In case when the page is not getting saved quickly (this is mostly the case with heavy pages e.g. in Cascade, Heatmap and VendorExtranet) we prefer keeping JS in a separate file. This saves a lot of development efforts because we will need to just open the JS and make all the changes.

Being a developer myself I know how irritating it is when SPD refuses to save the code you have written with so much of hard work. However, please refer to the first line of this section and you will that our aim while writing the code is always reduce PLT and nothing else. Here by keeping files externally you have made the job easier for yourself but PLT will suffer for the rest of page’s life. I do understand how difficult it is to follow this, but I will urge all of you to do it like this:

- During your development cycle keep your JS code externally.

- Once the page is finalized, open the page in browser and place the external JS content in a CEWP.

This will make sure you adhere to the best practices require to reduce PLT.

9. What would be an ideal alternative?

I would reiterate my point here “It is not recommended to have a page specific JS file and should be avoided in most cases”, however, if it unavoidable in certain case I would recommend having a dynamic script tag added to your page post load. Code for this approach can be found in the attached e-book, for your convenience I am attaching the code sample here:

Hope this article have answered all of your queries. Please, leave a comment if you need further clarification. However I would encourage you to comment only after you have also read attached links as I believe they must be able to answer all your queries.

Problem Statement: I have a SP 2010 project. This project contains a web part or some other component that requires an external dll should be present in server’s GAC or web application’s bin folder.

How do I do that?

Approach:

VS 2010 includes inbuilt capabilities to create wsp package files for all the supported SP project templates. Most of the times I would like to add some external dll to my project so that upon installing my solution to SP farm these dlls also gets copied. If you were doing this manually you would had opened your wsp cab and edited manifest.xml file(I will describe manual approach at the end of this article), but actually with VS 2010 you don’t really have to do this. It’s a piece of cake, just follow my lead:

o With your SP 2010 project open in VS 2010, double click on package.package from solution explorer.

o You will see the package designer window getting opened. At the bottom of this screen you will see three editor switches. By default designer window opens in “Design” mode. In order to be able to add additional dlls we will have to switch to “Advanced” mode.

So what are waiting for? Click on that gray looking button that says “Advanced”

Once in design mode you will see a nice looking UI with 3 buttons.

Initially the screen will be empty as there are no additional dlls defined. Let’s add some.

Click Add, and you will be prompted to selected external dll or dll from one of the opened Project output. For external dll select “Add existing Assembly”.

In the window that opens up just insert information about your external dll, such as:

- Where you would like to add that dll (GAC or Web app’s bin)?

- Whether any safe control entries should be made in target web app’s web.config file?

- Add resources (if any).

My test dll will be deployed into target server’s GAC folder and there are neither any safe control entries that I need nor it has any class resources. The final screen looks like:

o Click ok and that’s it. Just repackage your WSP by right clicking on the project and click package, and you will see that the resulting wsp will contain these external dlls automatically.

You are now done with whatever you wanted to do, don’t need to read any further. Those of you who really want to know what VS actually did internally can read on.

(you don’t really have to know, as in most cases you will be using the above approach only, but the good old developers who have used MOSS 2007 and are aware of the pain it used to cause can read on … to relive what a pain it really was)

Simulate what VS 2010 internally really doing:

· Rename your .WSP file to .cab

· Extract it.

· Copy dlls that your require at the root, or in some other folder.

· Edit manifest.xml file and add

For assemblies:

Here,

- Set Location to your custom dll’s location within extracted cab.

- Set DeploymentTarget to either of these 2:

o GlobalAssemblyCache for deploying this assembly to GAC on target server.

o WebApplication for deploying this assembly to Web application’s bin folder on target server.

For Safe controls:

I hope I don’t have to describe how to make safe control entries to a SP developer.

· Repackage this to cab. (For doing this I have always used tugzip)

· Once done rename file as .wsp.

Here,

1. 1.      “SharePoint – 19632”: is the name SharePoint site as shown in IIS.

1. 2.      Set “trustSection.Level" to

·         Full

·         WSS_Minimal

·         WSS_Medium.

1. 3.       TrustSection,Configuration, and WebConfigurationManager are memebers of WebConfigurationManager class which is present in System.Web.dll.

Issue: When clicking on the ECB menu in SP 2010 pages library I was getting the following error message.

This item is no longer available. It may have been deleted by another user. Click ‘OK’ to refresh the page.

Also upon selecting the item in library the ribbon control wasn’t getting enabled.

How I reached here?

I have upgraded from MOSS 2007 to SP 2010 and till this point the site was working fine. Then I did Visual upgrade and this issue started coming off on pages library, master page gallery etc. I tried various approaches in order to resolve this issue but was not able to.

Finally while trying various things I found a work around for solving this issue. (This is a work around as I am not aware of actual issue) Follow the steps given below in order to resolve this issue.

Somehow the OOB ListViewWebPart is corrupted for pages library, so in order to resolve the issue please replace this with XSLTListViewWebpart as mentioned.

- Open the site where you are facing the issue and navigate to “pages” library. In views section edit all documents view as explained below:

- On the page there will be a default listform webpart. Hide this web part as shown:

- Change IsVisible to false.

- Now simply insert a new XSLTListViewWebPart for the desired library and save the page.

- This should solve your ECB and ribbon issue.

One of the first things that I worked on in SharePoint was Live ID integration with SharePoint site, for one of my project. The resources were scarce at that time and had really tough time in trying to configure Live ID with our site, but finally made it. Below is the document that I prepared after i completed that project.

The WSP solution that this article talks about was at that time available only on Keith solanite’s  blog, but lately I m aware that the same package is also available on codeplex.

One thing that this article doesn’t talk about is the sign out issue, that I solved later on and is not documented. If any of you need clarification on why users are not able to be sign out from live network, kindly leave a note I will get back to you.

So here it goes. Enjoy

1) Deploying the Package

The following steps will guide you through the process of integrating Windows Live ID authentication with your SharePoint site.

Perquisites:

· You should have the WSP package which includes all the required files for integration of Windows live id authentication.

Deploying the Solution

In order to deploy the solution you need to make sure the WSP file is on the SharePoint server file system.

Run the following commands to deploy the solution

1. Change directory in to the directory you have downloaded the static.wsp file

2. Type: "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe" -o addsolution -filename Static.wsp

3. Type: "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe" -o deploysolution -name Static.wsp -immediate -allowgacdeployment

4. Type: "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe" -o execadmsvcjobs

This will install:

· C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\liveinfo.aspx

· C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\liveauth-handler.aspx

· C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG\stsadmcommands.addwindowsliveauth.xml

· GAC: WindowsLiveAuth.dll

These files will be installed on all servers in the farm.

With WSS 3,0 it is possible to create our own operations for stsadm commands, the above installation will create a new operation named “addwindowsliveauth”. This operation will be handling all the editing of the web.config file of the site to enable it to support the live id authentication. To be precise this command will going to configure the membership provider & role provider as well as the login page URL to a page that was deployed during the above installation in to the layouts folder inside 12 hive, which will going to handle all the authentication cases viz. sign-in & sign-out. The use of “addwindowsliveauth” is described in the later part of this document. Apart from this it will store the required information such as appId, Secret key, Authentication URL to use & other parameters.

2) Creating sites that will going to use windows live id authentication:

a) Create a web application:

Figure 1

Figure 2

In create a web application keep all the default settings (change the port number if you want to but remember the port number).

Figure 3

Note:

you can select search server to any configured SSP, but the search will not work in normal case ( i.e. unless you properly configure your farm) because we will going make this site FBA (Form Based Authentication) based & search , MySite services will not work with FBA because they need windows based account.

Implementing forms-based authentication can interfere with enterprise search functionality. To enable search across content authenticated using a custom authentication mechanism, you must have the Default zone configured to support NTLM authentication. The Office SharePoint Server 2007 search crawler polls zones in the following order:

Default zone

Intranet zone

Internet zone

Custom zone

Extranet zone

If you use forms-based authentication and the Office SharePoint Server 2007 search crawler polls a zone that is configured to support Kerberos authentication, the Office SharePoint Server 2007 search crawler will fail. If you use forms-based authentication and the Office SharePoint Server 2007 search crawler polls a zone that is configured to support basic or certificate authentication, you have to configure a crawl rule and provide credentials or certificates in the Shared Services Provider (SSP) search settings. If a crawl rule is not configured, the crawler will cycle through all of the zones until it finds a zone that is configured with NTLM. If the crawler finds a zone configured with NTLM, the crawl will succeed. If the crawler finds a zone configured with Kerberos or Digest authentication, the crawl will fail and polling will stop. (Refer Figure 4).

Figure 4

The user will be added as provider:username because the People Picker will resolve the user by using the provider configured in the Web.config file for the extended Web application. Office SharePoint Server 2007 ignores the custom provider if All Zones is selected in the Zone drop-down list. Therefore, it is very important to ensure that the appropriate zone is selected.

3) Create a site collection for the above web application

a) Click on create site collection link.

Figure 5

b) In create site collection page make sure the appropriate port number is selected in the web application drop down, if not then select change web application & select the port number that you want to configure with live id authentication.

Figure 6

c) Give appropriate title & select the site template you want to use (we will be using publishing site template in the subsequent figures).

4) Registering the site with live.com

Once the solution is installed you must make sure that you have registered your application with live.com. This will give you an Application ID and a secret key that you will use to identify your users to live.com and authenticate the response that will determine if the user is valid.

1. Login to https://msm.live.com/app/default.aspx
2. Click on the Register an Application link

Figure 7

1. The Application Name is a name you will use to identify your application.
2. The Return URL must be set to http://your.servername.com/_layouts/liveauth-handler.aspx (as in this case we set it to http://maqonelca01.maq.com:3911/_layouts/liveauth-handler.aspx).
3. The Secret Key is the "password" that will be used to sign the authentication responses.
4. Submit the registration.
5. Click on the Manage My Applications link.

Figure 8

Here, Manage My Applications page, you should remember the Application ID (this is the AppId you will need later) along with the Secret Key you used when registering the application.

5) Configure the Authentication Provider

Once you have the provider installed and the application registered you need to configure the system to use this information.

  To complete the configuration you must:

1. Go to the Central Administration home page
2. Click on the Application Management tab
3. Click on the Authentication providers link in the Application Security section
4. Use the Web Application drop down to ensure that the correct web application is selected

Figure 9

1. In the Zones list pick the zone you want to enable Live ID Authentication on (Default is probably going to be what you are looking for)
2. Select the Authentication Type to Forms
3. Enter a Membership provider name of LiveID
4. Enter a Role manager name of LiveRoles
5. Enable anonymous access.

If you need to explicitly grant anonymous access to a site collection, in the Anonymous Access section, select the Enable anonymous access check box for all sites within the Web application. To disable anonymous access for all sites within the Web application, clear the Enable anonymous access check box.

Note: If you enable anonymous access here, anonymous access can still be denied at the site collection level or at the site level. However, if you disable anonymous access here, it is disabled at all levels within the Web application.

If you won’t enable anonymous at the site collection level as well as site level your site will throw an access denied error when the user will try to log in with their passport ids.

i) To enable anonymous access to your site open your site first don’t set the FBA authentication in above step just set the anonymous acces to be true & use the default windows authentication to access your site. From site action menu select site actions->site settings->modify site settings -> advanced permissions

Figure 10

ii) Select anonymous access->and select anonymous access for entire web site. (It is better practice to store all your data on a authenticated site & create a sub site that will going to have anonymous access for the visitors).

Figure 11

1. In the Client Integration section, under Enable Client Integration, make sure No is selected, and then click Save. If you select yes, features that start client applications according to document types will be enabled. This option will not work correctly with some types of forms-based authentication. If you select No, features that start client applications according to document types will be disabled. Users will have to download documents and then upload them after they make changes.

Note:

For forms-based authentication, client integration is disabled by default. When client integration is disabled, links to client applications are not visible and documents cannot be opened in client applications; documents can only be opened in a Web browser. However, users can download documents, edit them in client applications locally, and then upload them to the site. Client integration is disabled by default when you use forms-based authentication. This is because client integration does not natively support forms-based authentication. You might be able to use many client integration features with forms-based authentication, and there are workarounds available to implement varying levels of client integration functionality with forms-based authentication. However, if published workarounds are inadequate, or if you find unexpected issues using workarounds, we do not provide support and there are no product changes to address these issues. If you plan to use client integration with forms-based authentication, you must fully test any available solutions or workarounds to determine if the performance and functionality are acceptable in your environment. Product Support can provide commercially reasonable support to help you troubleshoot published workarounds.

1. Click the Save button

This has configured SharePoint to use the new Membership and Role providers; however there is one more configuration step to configure the web applications to recognize the new providers.

6) Integrating the web application with Live ID:

a) Open command prompt

Type: "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe" -o addwindowsliveauth -appid <application id> -appkey <application secret key> -appmode <http/https – this is what url your users use> -profsite <URL of site that contains the profile list> -proflist <user profile list name> -locked <URL to send locked users to> -url <URL of the Web Application> -role LiveRoles -member LiveID

o Ex. Of the command for our site:

stsadm.exe -o addwindowsliveauth -appid 0000000048001E10 -appkey <your key> -appmode http -profsite http://maqonelca01:3911 -proflist LiveAuthenticationList -locked http://maqonelca01:3911 -url http://maqonelca01:3911 -role LiveRoles -member LiveID

Note:

o the ‘profsite’ is a site which stores the user list, it may be same as to which you want to apply live authentication & it can be different depending on the need.

o ‘locked’ is the url to which signed-out users will be redirected to.

o -role & member are the names of the role providers & membership providers, which will be used to authenticate the user.

b) You must run this command for every Web Application you wish to have access to this user list (i.e. the Web Application that will authenticate Live ID users and Central Administration if you want Live ID users to be able to own site collections etc).  The one difference when running the command for different Web Applications will be the -url parameter.

[Optiona step] you need to add the defaultProvider for the Web Application that will authenticate Live ID users, you will replace the following in the web.config for the Web Application:

o <membership> with <membership defaultProvider="LiveID">

o <roleManager> with <roleManager defaultProvider="LiveRoles" enabled="true" cacheRolesInCookie="true" cookieName="liveroles">

o You can find an example portion of the complete web.config here

c) Perform an IISRESET and you are done

Note:

• As a best practice you will want to have the profsite parameter set to a site that has restricted access as it will allow contributors to lock users.
• As a best practice the locked parameter should be a URL that has anonymous access and ideally has contact information about how to become unlocked.
• Live ID users will need to have the Edit Personal User Information permission added to whatever role they have on the site to have access to change their personal information.

7) Adding edit my profile option in the upper navigation section

Figure 12

Till this point you successfully configured windows live id into our SharePoint web application, now the next step is enabling user to edit the user information provided at the time of registration. For this we will going to add a Link just below the sign out option in the top navigation, so that user will be able edit his/her profile information.

The Solution that you just deployed, had already deployed the element & feature file needed for this purpose at

\12\TEMPLATE\FEATURES\WindowsLiveAuthenticationSettings

You just need to install & activate this feature. Here is how you will do it:

After activating, you need to do an IISRESET, and the site column should be available. In my case it is only available in the “tonportal” portal.

a) stsadm -o installfeature -filename WindowsLiveAuthenticationSettings\feature.xml [-force]

b) stsadm -o activatefeature -filename WindowsLiveAuthenticationSettings\feature.xml -url http://maqonelca01:3911

Troubleshooting Common issues

• Access denied error:

This is the most common error you will face, if the site is not configured properly. The problem here is that SharePoint doesn’t natively understand Live ID authentication so even though you authenticated users properly with their Live ID, SharePoint is unaware of this & will simply throw a security exception saying the current user is not authenticated for the current site. There are 2 solutions to this problem.

One will be to enable anonymous access at the site level & you are done, frankly it does solve the problem but this is not the optimum way since user is anyway able to access the entire site without getting authenticated then why on earth he will ever going to log-in?

Another better approach is to have one windows based site & another extended version of it which will going to use Live ID authentication. In this implementation you can actually add all the live ID authenticated users to particular group. You will not have to individually add each user taking their GUID rather you can do it by giving specific permissions to all the authenticated users. This is possible because, Live ID SDK (the wsp package that is deployed) comes with a OOB group, "Authenticated Live Users”, that includes all the users who are authenticated with their Live IDs, yes you guessed it, this is the Live ID FBA equivalent of "NT_AUTHORITY\Authenticated Users” used users, so you will just have to add this group to your site & you are done.

Note:

You will be able to add this group only on the site on which the Live ID authentication is integrated i.e. the extended web application but to have admin privileges (which you will need to add the group to the site), there you will need to add yourself as the admin to the site which you can very well do from the original web application giving your GUID (you can do this only if you are in some way added to the site, one way to ensure this is try to log in at least once because it creates your account even if it denies access to you).

Once you have the required privileges go to

Site Settings à People and Groups à Site Visitors and from the New menu, choose Add Users.

In the Users/Groups control, type in Authenticated Live Users and click on the Check Name button.

Figure 13

• Values Doesn’t fall within expected range:

This is another error that was observed a lot many times during the development. The reason behind this is simple in the code we are referring to a list which doesn’t actually exist, so just run the last command again which configures the list & it will solve the problem.

• Even after running the addwindowsliveauth command the site still redirects to default FBA login page rather than to the login page of live.com:

This is really a very peculiar problem & exists mainly on windows 2008 server machines. This is because the web.config file contains the URL of login page which should be set to live’s login page by the command but doesn’t actually happens like that so you manually have to do it. Track down the authentication node in config file & replace it with

<authentication mode="Forms">

<forms name="livelogin" loginUrl="/_layouts/liveauth-handler.aspx?action=login" /> </authentication>

• Even after adding user as admin, the site action menu doesn’t appear:

Another peculiar problem, again the issue is with the config file only. Here go & check both of your site’s (original application as well as of extended application) web.config file & see if the following nodes exist as they are given below.

a) Make sure that the Web.config of the Windows zone has the following nodes:

<membership>

<providers>

<add name="LiveID" type="CKS.WindowsLiveAuthentication.LiveMembershipProvider, CKS.WindowsLiveAuthentication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5adbad25a892e4a" />

</providers>

</membership>

<roleManager >

<providers>

<add name="LiveRoles" type="CKS.WindowsLiveAuthentication.LiveRoleProvider, CKS.WindowsLiveAuthentication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5adbad25a892e4a" />

</providers>

</roleManager>

b) Make sure that the Web.config of the Windows Live zone has the following nodes:

<membership defaultProvider="LiveID">

<providers>

<add name="LiveID" type="CKS.WindowsLiveAuthentication.LiveMembershipProvider, CKS.WindowsLiveAuthentication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5adbad25a892e4a" />

</providers>

</membership>

<roleManager defaultProvider="LiveRoles" enabled="true" cacheRolesInCookie="true" cookieName="liveroles">

<providers>

<add name="LiveRoles" type="CKS.WindowsLiveAuthentication.LiveRoleProvider, CKS.WindowsLiveAuthentication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5adbad25a892e4a" />

</providers>

</roleManager>

• If you have some other problem with integrating Live ID into your site & you tried all the above steps as a final resort check in your config file of both windows zone as well as windows live zone that they contain the following nodes.

• For windows zone:

<appSettings>

<!– The Application Id comes from your registration of the application at https://msm.live.com/app/default.aspx –>

<add key="WLA_ApplicationId" value=" YourApplicationID" />

<!– This is the shared key that you created when you registered your application –>

<add key="WLA_ApplicationKey" value=" YourApplicationKey" />

<!– In general this should not need to be changed, but if you want to use a different algorithm you can –>

<add key="WLA_ApplicationAlgorithm" value="wsignin1.0" />

<!– This can be http or https your preference –>

<add key="WLA_ApplicationMode" value="http" />

<!– This is the URL to the site that houses your Profile list. This should be a site collection that is on the current farm –>

<add key="WLA_LockedUrl" value="http://YourURL" />

<!– Profile list name. This can be changed if you need to –>

<add key="WLA_ProfileList" value="WindowsLiveID" />

<!– This is the URL to send users who validate properly, but have had their accounts locked by an admin. This URL should allow anonymous –>

<add key="WLA_ProfileSiteUrl" value=" http://YourURL " />

</appSettings>

• For Winodws Live Zone:

<appSettings>

<!– The Application Id comes from your registration of the application at https://msm.live.com/app/default.aspx –>

<add key="WLA_ApplicationId" value=" YourApplicationID" />

<!– This is the shared key that you created when you registered your application –>

<add key="WLA_ApplicationKey" value=" YourApplicationKey" />

<!– In general this should not need to be changed, but if you want to use a different algorithm you can –> <add key="WLA_ApplicationAlgorithm" value="wsignin1.0" />

<!– This can be http or https your preference –>

<add key="WLA_ApplicationMode" value="http" />

<!– This is the URL to the site that houses your Profile list. This should be a site collection that is on the current farm –>

<add key="WLA_LockedUrl" value="http://YourURL" />

<!– Profile list name. This can be changed if you need to –>

<add key="WLA_ProfileList" value="WindowsLiveID" />

<!– This is the URL to send users who validate properly, but have had their accounts locked by an admin. This URL should allow anonymous –>

<add key="WLA_ProfileSiteUrl" value=" http://YourURL " />

</appSettings>

I received a request from a client recently. The said client wanted to find out whether MOSS 2007, maintains different versions of the documents from a document library for which versioning is not enabled?

Well the oblivious reply was NO (capitalization here is intentional).Period.

But the client has a business situation and he needed it anyhow, so the next question he asked actually kind of stumped me. He said if the versioning is not maintained then how MOSS is able to tell you that this is the 5^th or 6^th version of a document. So that got me thinking and I went on to do the formidable, i.e. I queried MOSS db. Find the results below of my findings.

· The OOB part:

How MOSS versioning actually works:

Once you turn on versioning on a document library, you’re enabling the use of a new “virtual” directory set aside for the sole purpose of providing a “web” interface to access previous versions of a document that are all stored in the content database.  This new directory is called “_vti_history“, and includes a number in each document’s URL that signifies it’s actual version – it’s also important to note that all the documents accessed in the virtual folder are previous versions of the document only, not the current version that is displayed in the document library itself (this will be important to remember later when programming on versions).

An example of these URL’s for document versions would be something similar to:

http://girishm:1301/_vti_history/1/Shared%20Documents/Test.doc

http://girishm:1304/_vti_history/2/Shared%20Documents/Test.doc

http://girishm:1304/_vti_history/3/Shared%20Documents/Test.doc

http://girishm:1304/_vti_history/512/Shared%20Documents/Test.doc

http://girishm:1304/_vti_history/1024/Shared%20Documents/Test.doc

http://girishm:1304/_vti_history/1025/Shared%20Documents/Test.doc

http://girishm:1304/Shared%20Documents/Test.doc

(The last URL listed does not contain a number or the “_vti_history” path because it is the current version of the document.)

You’ll notice in the URL’s the number immediately following the “_vti_history/” part of the address.  This number specifies exactly what the version number is for the document.

URL number “1” = version “0.1“

URL number “2” = version “0.2“

URL number “3” = version “0.3“

URL number “512” = version “1.0“

URL number “1024” = version “2.0“

URL number “1025” = version “2.1“

So, by looking at these numbers, we can start to see a pattern forming. You’ll notice that all the minor versions (numbers to the right of the decimal point) are all based on a single number counting system, whereas the major versions (numbers on the left of the decimal point) are based on a “512″ increment system (I like to call this a “base-512” counting system).

For example, let’s say we have a document that is version “14.7″.  Following the pattern and the base-512 counting system, we’d come up with a number of “7175″ (512 * 14 + 7) making the URL http://girishm:1304/_vti_history/7175/Shared%20Documents/Test.doc.

For non-versioning enabled lists _vti_history virtual directory doesn’t exist so it’s not possible to access various versions of the same document.

· Dissecting content db:

For this exercise we created 2 lists:

Documents (this library has versioning enabled) – only one document is uploaded in this library versioneddoc.txt

Without Versioning (this library doesn’t have versioning enabled) – only one document is uploaded in this library links.txt

For this web application the content db name is: WSS_Content_5500

All the information regarding the documents is stored in one single table : AllDocs

All the versioning information for the document is stored in one single table: AllDocVersions

Actual steps:

Run the following query:

USE WSS_Content_5500

SELECT AllDocStreams.Id, AllDocStreams.[Content], AllDocStreams.Size, AllDocs.Version, AllDocs.TimeLastModified, AllDocs.CheckoutUserId,

AllDocs.CheckoutDate, AllDocs.IsCurrentVersion, AllDocs.DirName, AllDocs.LeafName, AllDocs.[Level]

FROM AllDocs INNER JOIN

AllDocStreams ON AllDocStreams.Id = AllDocs.Id AND AllDocs.[Level] = AllDocStreams.[Level]

WHERE (AllDocs.DirName = ‘Without Versionings’) AND (AllDocs.LeafName = ‘links.txt’)

O/P

USE WSS_Content_5500

SELECT AllDocStreams.Id, AllDocStreams.[Content], AllDocStreams.Size, AllDocs.Version, AllDocs.TimeLastModified, AllDocs.CheckoutUserId,

AllDocs.CheckoutDate, AllDocs.IsCurrentVersion, AllDocs.DirName, AllDocs.LeafName, AllDocs.[Level]

FROM AllDocs INNER JOIN

AllDocStreams ON AllDocStreams.Id = AllDocs.Id

WHERE (AllDocs.DirName = ‘Documents’) AND (AllDocs.LeafName = ‘versionedDoc.txt’)

O/P

Both these o/p indicates that there are 3 versions for these documents (which is true as I edited both of these document 3 times) so this being the first version where are the other 2?

Yes, the other versions must be in AllDocVersions. Now let’s query AllDocVersions and see if we can get the other 2 versions for these documents:

For ‘Documents’ library:

SELECT a1.[Id],a2.Version

FROM [WSS_Content_5500].[dbo].[AllDocs] as a1, [WSS_Content_5500].[dbo].AllDocVersions as a2

where DirName = ‘documents’

and a1.Id=a2.id

O/P

Got it! So here are the other 2 versions (1^st and 2^nd major version) for the list for which versioning was enabled.

Now let’s try and see if we can get the versions for the document for which versioning is not enabled:

For ‘ Without Versionings’ library:

SELECT a1.[Id],a2.Version

FROM [WSS_Content_5500].[dbo].[AllDocs] as a1, [WSS_Content_5500].[dbo].AllDocVersions as a2

where DirName = ‘Without Versionings’

and a1.Id=a2.id

O/P

No versions were found.

Conclusion: From the above 2 exercises it is clear that the versioning information, for the library for which versioning is not enabled, is not available.

So as the world will have it, I was Right.

Using SPD Broken Link Checker

There are many tools available online which can help you scan broken links, such as Xenu etc. But when it comes to SharePoint these tools are not really that useful since they consider even the documents as a link, so if you are having a document heavy site with a lot of document libraries and documents make sure your are have plenty of time before you even consider running these reports J.

To make things easier SharePoint Designer (SPD) comes with build in functionality to scan and report broken links in your website, and at the time of this writing this is the best tool you can use in order to scan broken links in a SharePoint web site.

How To

In order to be able to scan links for your SharePoint site using SPD follow the steps given below:

1. Open your site in SPD.

2. From the menu bar select SiteàReportsàProblemsàHyperlinks (alternatively you can also press ALT+S+R+P+H)

3. SPD will now prompt you about the process click “Yes” to continue.

4. Once Completed, you will get a screen as following:

5. In the report you will the following legends being used:

Note: Unknown links are those which SPD is not able to verify. For such links you will have to run the scan again. To do so, click on the link you want to verify again (you can select multiple links at a time either by CTRL+A, or any other technique you are familiar with) and right click and select “Verify Hyperlinks” from the context menu.

Fields available in this report

By default, following fields will be available in SPD broken links report.

· Status à Refer This

· Hyperlink à The URL of the link

· In Page à Relative Page URL

· Page Title à Title of the page

· Destination à Internal or External

· Type à image or normal link

· Modified By

Applying filters on the report

You can apply filters on the existing reports, by selecting the field you want to filter on from the top of the report and then selecting your desired criteria by clicking on the inverted chevron that appear on the side of each field.

You can also create your own custom filter,, by clicking on (Custom…) option, that will open the following window where you can specify your filter criteria.

Understanding the context menu

Normal context menu in the reports pane will look like

· Edit Hyperlink:

Select this option if you want to change the link directly from reports pane itself. Upon clicking this option you will be presented with the following screen from where you can directly replace the destination for the given hyperlink.

Note that you can also select whether you want to replace this link in any one page or all of the pages. The list box at the bottom will list all the pages in which this link appears and you can selectively choose to replace this link in certain pages, by selecting the pages from the list box.

· Edit Page:

Click on this action if you want to open the selected page for editing.

· Verify Hyperlink:

Use this option to verify unknown links.

· Show Internal Hyperlinks:

The SPD hyperlink report categorizes the links in report as following types based on the destination.

§ Internal links

§ External links

Select “Show Internal Hyperlinks” option to see only internal links in the report.

· Copy Report:

Select this option to copy the entire report data to clipboard, which you can then use to export this report into other formats (such as into a word file or excel sheet).

· Remove Filters:

Use this action to remove whatever filter you have applied on the report.

· Site Settings: Simply opens the site settings dialog box of SPD.

Summary

Broken links are the most common errors which leaves a very bad impression on your client. Consider a situation when you click on a link given in a site’s home page and that leads you to the forbidden 404 page. Being a developer myself I can surely say that you don’t want your clients to stick on a 404 page. As shown here hyperlink checker is really a nice hidden functionality of SPD, with a lot of features incorporated such as filtering, export report, as well as fixing broken reports from the reports pane itself. SPD broken link checker has its own application in SharePoint environment where other traditional link checkers proves to be ineffective.

With these insights into the tool, I would recommend that we should mandatorily use SPD broken link checker for all our SharePoint sites.

Many times while working with SPD (SharePoint Designer) 2007 you get the error saying “Cannot perform this operation. The file is no longer check out or has been deleted” even when in the SharePoint galleries the page, master page, page layout or the CSS file is shown as perfectly checked in or in another case SPD will keep asking you to detach the page from the layout which is already detached etc. These issues basically occur because SPD web cache is out of sync with your MOSS site. Here simply clearing your IE cache is not going to solve the issue rather you have to follow a little different approach, as given below:

· In SPD, from the menu bar go to Site Settings

· From the modal window that opens, select Advanced tab and click on ‘Delete Files’.

· Now in order to clear ASP.net cache we will have to delete files from the following location

%UserProfile%\AppData\Local\Microsoft\WebsiteCache

%appdata%\Microsoft\Web Server Extensions\Cache

You can manually delete these files or create a batch file as given below and run it each time such issue occurs.

· Create a batch file and paste the following code into it (you can actually put this in a batch file):

· Delete the directory with your site’s name from the following location

%USERPROFILE%\Local Settings\Application Data\Microsoft\WebsiteCache

· Restart SPD.

Hope it helped

As you all may know Microsoft officially unveiled SharePoint 2010 to the world on 19th October 2009 9 AM PST. See the keynote opened by Steve Balmer himself here .

I know I shouldn’t be calling it MOSS any longer as Microsoft decided to do away with “Office” in the name, and very rightly so. A great product as the SharePoint is shouldnt be allowed to be shadowed by another great product is’t it ? Anyway there is no official acronym for SharePoint 2010 just yet, so we will have to do with the full name. (Anyway those of you who are hurriedly thinking why it can’t be called MSS, just google it out).

I will be posting about SharePoint 2010 on this blog starting sometime soon. Hope it will help you guys who are planning to start off early with this great new product.

This is a great product and will surely going to break standards it created for itself back in 2007 when no one had such expectations from it. A lot of eyes are monitoring the progress of this new release and from my point of view it will surely going to live up to the expectations.

Just stay tuned if you want to learn about this new product all by yourself.