Wednesday, June 25, 2008

Setting an alternative home page of portal in place of the default.aspx portal home page

Over time I've heard this request coming in several times, so this is the time to share my idea on how to make it happen. so far I've found this the easiest and quickest way. I'll talk about trade offs at the end.

This technique involves a couple of steps:

1. Add Content Editor Web part anywhere on your Portal home page, this web part will not be visible to end users, this is why placement does not matter.

2. Edit content of this Web Part through the HTML editor option available in the WP.

3. Paste the following script in there

<script type="text/javascript">

var start = document.cookie.indexOf( "MyPortalHome=" );

if (start < 0) {
     document.cookie = "MyPortalHome=Something";
     document.location.href="[my desired url]";
}

</script>

4. Replace [my desired url] with the url of your alternative home page

5. Save you changes :-)

Lets see what the script does:

var start = document.cookie.indexOf( "MyPortalHome=" );

 

This way we are checking for existence of the "MyPortalHome" cookie by setting "start" variable to the index location of the "MyPortalHome" cookie.

 

if (start < 0) {

if the cookie exists "start" variable will be more than -1, it will represent the actual start position of the cookie, if it is -1 then the cookie does not exist, meaning this is the firsts time user clicked on the portal url within this browser session. if this is the case we will execute the code below.
     document.cookie = "MyPortalHome=Something";

We are setting the cookie

     document.location.href="[my desired url]";

And redirecting users to the alternative Home Page.

If the cookie exists we are doing nothing. It will indicate that user got to this page before. T

he cookie will expire as soon as the user closes the browser, next time the user goes to the portal url the cookie will be set again and they will get redirected to the alt. home page.

Gotchas:

1. if the user opens a new tab in IE and goes to the portal home, the cookie will persist and they will not get redirected, only when the browser is closed the cookie will expire with the end of the session.

2. To set the cookie in the browser you will have to allow to execute the script, you can prevent this behavior by modifying your security settings for this zone, or add this site to a list of trusted sites.

Have fun

Thursday, June 19, 2008

SharePoint portal implementation approach

I was very excited to have an opportunity to write an article on the SharePoint implementation approach best practice topic for TechTarget. Unfortunately due to article's length limitation which I absolutely agree with (who has time to read lengthy article) I had to be very concise, but I’ve tried at least to mention the most important points.

The biggest challenge though is initial light weight approach to the SharePoint implementation project by the client. Most of the time companies view SharePoint as just another application to get their hands on. They do not understand that it is a platform which implementation demands a careful planing and design. Hopefully this message will get through to them and we will have to spend less time justifying the cost of the discovery and initial design phase and more time on building the most flexible and reliable platform.

Here is the link to the article http://searchsystemschannel.techtarget.com/tip/0,289483,sid99_gci1317689,00.html

WebDav interface within the SharePoint library

While the WebDav interface within SharePoint libraries provides a very useful function of opening the library and the whole Site collection structure through the Windows Explorer application, it might be more detrimental to your SharePoint solution then you think. Let me explain one business scenario where you will run into problems when using this;

Let's say your users want to edit PDF files from task view generated by a workflow that provides them only a link to the originating file. You know the outcome... the browser will open the file within it's self without the ability for users to save the document after editing into the source location (which is the SP library in this case), the doc will have to be saved onto their local HD and then re-uploaded into the library. What happens to the original document's metadata??? Yep, it's lost, the document is now a new entity within the library. Or the PDF file will be opened in Adobe Acrobat, but again without the ability to save this file into the source location.

In this case it seems that Adobe is fighting with Microsoft.

I've went around this restriction by opening the link to the PDF using WebDav interface (you can find the description here). You might think this is an answer to your question, if you make sure that all your desktops are OK for this.

After implementing this solution and reading a lot of different forum questions and comments on the usage of (citing) "Open in Windows Explorer" functionality, I've come to realization that people do not understand components involved into this functionality. OK, let's talk about one of the major issues that people are trying to troubleshoot: "why for some users this works fine...  the explorer opens quickly and they can manage the documents. For other users it takes up to 5 minutes before the explorer view opens.  During this time the browser becomes completely unresponsive."

First of all, it is not an issue on your SharePoint environment but it’s a problem on the desktop

Two words - "Web Folders Client" :-)

The webfolder functionality is implemented by means of MSDAIPP.DLL this is the DLL that is responsible for WebDav interface functionality. It usually resides inside "C:\Program Files\Common Files\SYSTEM\OLE DB" or it's language dependant equivalent (such as "C:\Programme\Gemeinsame Dateien\SYSTEM\OLE DB" for German Windows versions). To find the DLL version, select the file in Explorer, choose "Properties" from the right-click context menu, then select the "Version" tab.

Here is the link to the posting that explains it all. http://greenbytes.de/tech/webdav/webfolder-client-list.html

Do not expect all your desktops to have the same "working" version of Web Folders.

Another one: "when MS Office document is edited users have trouble saving the document back to the library"... well, there are several variations to the errors they are getting, but I'll not list them all, simply because I have not seen ALL of them.

In this case it is directly related to the user's rights to the desktop in relation to the account the user is logged into the SharePoint with (presuming that user logged into the desktop is not the account used to log into SharePoint). If the user does not have sufficient rights to this desktop, than FORGET IT unless you add the user account to the local desktop group. While this is not such a common scenario, because of the ways most of the networks are setup, but the case I'm describing here is when a number of users is relatively small within the company and IT decides that a user account expected to be used at this particular workstation should be added manually into local desktop group.

Before you start using WebDav interface make a number of considerations:

1. Are your desktop images are "STANDARD" (and do not use the definition of "standard image" loosely)

2. Are you ready to maintain the web folders component individually on all desktops if they vary in applications and versions of apps. that are being ran locally.

If your users are local admins on their desktops, may god help you then. J

Enjoy

 

Wednesday, June 18, 2008

Restoring PORTAL site collection from one farm to another

When you backup portal site collection from Farm1 and try to restore it  not as a portal site collection on Farm2,  but as  a site collection within a managed path, I'm afraid it not possible.

Even after several tries to do it, all I was getting was overwritten portal site collection on the farm that I tried to restore it to. So before you attempt to restore PORTAL Site Coll. into managed path Site Coll. be careful as this action most likely will overwrite your existing Portal Site collection.

And if you found a way to do it without overwriting  Portal Site Collection on the existing farm, leave a comment and let me know how.

Thanks

Monday, June 9, 2008

Event handler on a document library with custom editform

Even though this is probably a known issue, but I've been looking everywhere to find some information on this specific case and nothing surfaced. Here it is, the ERROR :-)  (the big, bad, SP error)I've been receiving "The data source control failed to execute the insert command." after filling out a metadata on a document within the document library with event handler (that fires up upon add item event).  Cause:  as part of my metadata I have a lookup column that is based on a list within the site and has "Allow multiple values" checked. Why it seemed that the event handler is cosign it? Well, I have another doc library with similar setup but there is not event handler behind it and it works just well. By the way it's not just a combination of Event handler and multiple choice lookup field, I also have a custom EditForm.aspx. Only after deleting my lookup field and recreating this field as a Choice field this problem has been resolved. And no, this is not SP1 environment. Hope it helps

SharePoint, event handler, Document library, custom edit form, multiple lookup field

Thursday, June 5, 2008

PDF Saga continues

Adobe, adobe...

One of our clients had asked for a very sophisticated library to support their company's legal communication review process. All the audit information is being kept in a version history of a document. The problem started when they started editing PDF document by applying the "Redaction" tool of Acrobat, by design you cannot save the original document, you can only save the edited document using "Save as".

When Redaction is applied to the document, the document is being stripped of all original information and metadata to protect the document’s original information. In order to achieve this level of document protection, the document must be saved as a new document which removes the original document from the SharePoint library and saves the “redacted” document as a new entity.

As soon as the document had been "saved as" within the SP library it gets a new item ID associated with it, this way preventing any already running workflows to be completed and removes all original metadata information. If you try to complete a workflow task associated with this "Redacted" document, it will give this error: "The data source control failed to execute the update command." because the original item associated with this workflow does not exist anymore.

I recommend that you do not to use redaction tool at all within a SharePoint library, resort to the use of “revision” tool, or don't expect this document to have anything in common with the original document.

By the way, the same applies to any Microsoft Office document which is "saved as" even if it is saved over the original doc by replacing it, but at least within Office you have to intentionally choose to "Save as". But with adobe "redaction" tool you are forced into "save as".

I guess people have to be educated on the purpose of "redaction" feature, if it was behaving any differently, it would completely defeat the purpose of “Redaction” tool.