I was digging through MSDN today working on another issue and stumbled upon this nice link, http://msdn2.microsoft.com/en-us/library/ms478597.aspx which lists the Protocols you can use with WSS v3.0.  I knew about the Remote Procedure Call which uses Frontpage Extensions.  The other 2 protocols were basically new to me, but pose some interesting options for ways to work with WSS v3.0. 

Stssync protocol - "The stssync protocol enables you to add an Events list or a Contacts list that exists on a Windows SharePoint Services site to Microsoft Office Outlook 2007 or to a third-party application that supports the protocol."

Url Protocol apparently as I found out uses the owssvr.dll to process commands sent to it.  It allows you to get data out of a list in HTML or CAML.  You could then take the CAML, parse it, and embed the results in your custom application.

 

These 3 protocols give you some interesting ways to get data out of your SharePoint installations, use them in your other apps, further cementing SharePoint in your workplace.  What this also means is that by adding these into your toolbelt, you make your self not just a SharePoint developer, but a SharePoint developer that can help tie your companies business applications together, no matter what language the apps are written in, distinguishing yourself and making yourself more valuable.


Posted in: Sharepoint  Tags: , ,

I've spoken about this a few times in my presentations on the topic, but I don't think I ever blogged about it.  Basically to get ASP.NET AJAX to fully with with SharePoint 2007, you need to include some Javascript "fix" code which allows the ASP.NET AJAX to function properly. 

According to Microsoft, the reason for this code is the following "For ASP.NET controls that use the JavaScript _doPostBack() function to commit changes, a regular full-page postback event may occur even when the Web Part is inside an UpdatePanel control. Windows SharePoint Services 3.0 and ASP.NET AJAX cache certain form actions, which can cause a conflict between SharePoint and ASP.NET AJAX. To change this behavior, you must add code to scripts that are running in Windows SharePoint Services 3.0"

Below is the code you'll need to include in your Web Parts.

private void EnsurePanelFix()
{
   if (this.Page.Form != null)
   {
     String fixupScript = @"_spBodyOnLoadFunctionNames.push(""_initFormActionAjax"");
     function _initFormActionAjax()
     {
       if (_spEscapedFormAction == document.forms[0].action)
       {
         document.forms[0]._initialAction = 
         document.forms[0].action;
       }
     }
     var RestoreToOriginalFormActionCore = RestoreToOriginalFormAction;
     RestoreToOriginalFormAction = function()
     {
       if (_spOriginalFormAction != null)
       {
         RestoreToOriginalFormActionCore();
         document.forms[0]._initialAction = document.forms[0].action;
       }
     }";
   ScriptManager.RegisterStartupScript(this, 
     typeof(YOUR_WEBPART), "UpdatePanelFixup", 
     fixupScript, true);
   }
}
 
This code comes straight from Microsoft and you find it at http://msdn2.microsoft.com/en-us/library/bb861877.aspx
I've successfully been using the following code in my web parts without issue (for the life of me, I can't remember where I found it).
 
private void EnsureUpdatePanelFixups()
{
    if (this.Page.Form != null)
    {
        string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];
 
        if (formOnSubmitAtt == "return _spFormOnSubmitWrapper();")
        {
            this.Page.Form.Attributes["onsubmit"] = "_spFormOnSubmitWrapper();";
        }
    }
    ScriptManager.RegisterStartupScript(this, typeof(Demo01SimpleWebPart), "UpdatePanelFixup", "_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;", true);
}
So the choice is yours as to which one to use. I've been sticking with the one I've found and have tested pretty thoroughly, but I'd like to think that the MS way is probably more "supported".

Posted in: Sharepoint  Tags: , ,

I've set up FBA (Forms Based Authentication) on a SharePoint site a few other times, but never on Mysites.  Typically I follow Dan Attis's blog posting, which covers setting up FBA.  Dan also has another great post about setting up FBA with MySites.  Basically since MySites is tied to the Shared Service Provider, you have to setup FBA on both the SSP, and the site that hosts MySites.  I followed Dan's steps to the T but still ran into some issues.  Once I converted the SSP fully over to FBA, I wasn't able to get into all parts for configuring MySites that I needed, I would get errors telling me I didn't have permission.  What gives?  I followed Dan's steps, added an FBA account as an admin in the site, why would I be getting these errors?

So I backed out setting my SSP to FBA and set it back to Windows Auth and started taking a look at the permissions.  Everything looked fine.  Then I stumbled across the problem.  When your in your SSP and go to MySite Permissions, below is a screenshot of what a typical SSP MySite Permissions looks like.  Notice how you don't see your FBA admin account anywhere. 

image

So I added my FBA account and gave it the same permissions as my Windows Auth Admin account, switched my SSP back to FBA and viola!  I was able to now fully administer the SSP with my FBA admin account.  Notice how the spadmin account has the same permissions as my Windows Auth account.

image

 

Another thing to not here is the "everyone" group.  Dan talks about making this group in his posting, and it especially comes in handy when you want to do straight FBA with MySites.  I created the Everyone group and gave it the same permissions as the "NT Authority\Authenticated Users", which makes sense that you have to do this.  If you DIDN'T have an everyone group (or at least a group of users that COULD create MySites), you'd have no way for a FBA user to automagically create their mysite.  So by adding an "everyone" group and mimicing the "NT Authority\Authenticated Users" group, you now allow any authenticated FBA user to be able to create their MySite.

 

Here are the 2 links to Dan Attis's FBA walkthroughs.  They really are great resources and I can't thank Dan enough for posting them and helping everyone out most likely pulling his hair out discovering the secret of the SharePoint FBA.

Dan Attis's 2 part posting about FBA Part 1 : http://devcow.com/blogs/jdattis/archive/2007/02/23/Office-SharePoint-Server-2007-Forms-Based-Authentication-FBA-Walkthrough-Part-1.aspx

Dan Attis's 2 part posting about FBA Part 2 : http://devcow.com/blogs/jdattis/archive/2007/03/01/Office-SharePoint-Server-2007-Forms-Based-Authentication-FBA-w-MySites-Walkthrough-Part-2.aspx


Tony Testa posted on March 19, 2008 13:32

Ran across this issue the other day at a client.  I was setting up Forms Based Authentication for a SharePoint site collection and naturally created another Zone for it like I had a multiple times in the past.  Problem was, it turns out that we didn't want it to be like the typical multiple site collection (one with Windows Auth, and the other with FBA), so I was left with an extra zone DOH!

If there is a way to delete it through central admin then I must have missed it.  Below is the only command to my knowledge that will let you delete an extra Zone from your site collection.

 

stsadm.exe -o unextendvs -url http://yoursite:portNo -deleteiissites

 

Once again, stsadm.exe saves the day and gives me another reason to despise the Central Admin UI.


In my experience, the line between Dev. and DBA isn't always clear.  In the absence of a true DBA, guess who ends up being expected to enforce Database best practices?  Thats right, the Dev. is expected to know everything a DBA would be expected to know.

A few years back, the only thing I knew about databases was 3rd normal form, Primary Keys, Foreign Keys......that about sums it up.  I don't think I'm far off by assuming that most devs know about the same.  In the recent years though I've been fortunate enough to be throw at some more DBA type assignments and was able to learn more of the DBA roles' responsibilities.

In my more recent development projects, I find more and more that I'm asked, or expected to know more advanced database concepts.  Things like indexes, database integrity checking, truncating large log files, etc.

Luckily, SQL 2005 makes these more DBA tasks pretty easy to perform by way of a Database Maintenance Plan.  You can create a nightly job that will check your databases, shrink your logs, rebuild your indexes and backup your databases.  These simple tasks will help keep your databases performing optimally in addition to making you appear to know more about databases.

Bill Baer has put out a great MS white paper about Database Maintenance pertaining specifically to SharePoint.  It walks you through the steps that you should be doing to keep your SharePoint databases running at their best.

SharePoint aside, the white paper is just a good reference document about what you should be doing in general for your production databases, so I encourage any developer to read it.

 

Check out the white paper here.


Posted in: Sharepoint  Tags: ,
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017 Tony Testa's World