If you want to use OWA webparts with Integrated Authentication or Basic and have it default to the user that is logged on, the steps are simple - leave the username blank (see below).

But if you have done that you may be surprised to find that it continually prompts you to log in on that page EVEN THOUGH YOU ARE ALREADY logged on.

Not putting in the info gives you a beautiful 401 error: 

Luckily the resolution is simple.

What you want is that you will be logged on to the mail server with the current user name and password. But if you open up the security settings on your browser you will find out that this is not the option.

There are two ways to resolve this - both involve changing the setting. You can either change the zone that it defaults to (ie make Local Intranet always do 'Automatic logon with current user name and password') or you can put the mail server in the Trusted Zones.

I like the latter.

Go into the Securities tab, click on 'Trusted Sites' icon and then click on the 'Sites' button.

Once you are in there you can add the FQDN of the mail server (since you will be using its cert)...

Voila!!! 

Note: if you want to do this on a larger scale I would suggest you turn to your handy-dandy Group Policy editor. You can find what you are looking for User Configuration / Windows Settings. I will leave the rest of the steps up to you...

<rules>
  <rule>
    <path>http://YourFormsAuthSite/*</path>
<type>FORM</type> <error_pages> <error_page>Logon.aspx</error_page>
</error_pages> <auth_url>Logon.aspx</auth_url> <login_type>POST</login_type>
<parameters> <param name="__VIEWSTATE">dDw0OTQzMjI0MjQ7O2w8UGVyc2lzdDs%2BPvhWhKKTnHpM3RIvgkgC9jJVpN%2Bg</param>
<param name="Login1%24UserName">FormsAuthUserName</param> <param name="Login1%24LoginButton">FormsAuthPassword</param>
<param name="Login1%24LoginButton">Log+In</param> </parameters>
</rule> </rules>

1. They have incorrect fieldnames (missing the Placeholders) and note the repetition of LoginButton for the Password portion of the XML demo. Obviously someone simply cut and pasted sections rather than pasting a complete, correct, XML
2. They do not have __EventValidation. Testing this with Fiddler emphasized the need for that
3. They do not have public="true" in their params which can be useful - public: If this value is not present, the parameter specified will be encrypted and stored in the search system. For encrypted parameters, the size limit is 1,024 characters. If you specify public = "true", the parameter will not be encrypted before storing in the search system. Also, the parameters size limit increases to 4,096 characters. 

• Make sure the entries on both sides of the params are htmlencoded - use http://meyerweb.com/eric/tools/dencoder/ if you need help...
• Remember that this DOES NOT do security trimming. You still need to setup an FBA security trimmer - see http://technet.microsoft.com/en-us/library/bb852172.aspx#moss12_SearchFormsAuth_ImplementSecurityTrimmer for info on that...

I was installing a new Sharepoint Server in the farm, mostly because the currently had was too small.

I ran into errors with the Office Server Web Services (it kept saying it could not find the path, although the path to that website was fine (I checked it three times). The Root virtual directory could not be found...

I tried many things. Finally I ran the Office wizard to remove the new server from the farm. I then ran it again to reinstall it (after making sure that various dbs had the Sharepoint Server as a user - see previous log). And I got the error below:

The error in the log informed me that I it was missing the location of the Diagnostics Logs that I had moved to the E: drive on the old, slow server. So I moved the Diagnostics logs to the D: drive before running the wizard to try to join the farm again. No dice. Same error. I moved the logs back to there original locale in the 12-spot. No dice.
 
I try renaming the D: drive to E: - it refuses.
 
On the point of uninstalling/reinstalling MOSS on the new server I hesitate...
 
Searching through Regedit in the NEW server (not currently on the Farm) I find an entry in HKLM\Software\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS called LogDir. And guess what is in it? You got it - a reference to the entry on the E: drive...
 
Manually changed the regedit entry to match to the new d: location (on both servers) and VOILA!!!
 
So be warned - if you move the Diagnostics Logs location in a farm, a folder must be available on ALL servers (makes sense).
 
And the Office Server IIS site is gone. Probably a carryover from before...

Here is a snippet I created that I like to use when defining properties for webparts. Have fun with it...

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
   <CodeSnippet Format="1.0.0">
      <Header>
         <Title>Sharepoint WebPart Property</Title>
         <Shortcut>wpprop</Shortcut>
         <Description>Code snippet for Sharepoint Webpart Property.</Description>
         <Author>Matthew Mcknight</Author>
         <SnippetTypes>
            <SnippetType>Expansion</SnippetType>
         </SnippetTypes>
      </Header>
      <Snippet>
         <Declarations>
            <Literal>
               <ID>type</ID>
               <ToolTip>Property type</ToolTip>
               <Default>string</Default>
            </Literal>
            <Literal>
               <ID>property</ID>
               <ToolTip>Property name</ToolTip>
               <Default>MyProperty</Default>
            </Literal>
            <Literal>
               <ID>field</ID>
               <ToolTip>The variable backing this property</ToolTip>
               <Default>_myProperty</Default>
            </Literal>
            <Literal>
               <ID>personalizable</ID>
               <Type>System.Web.UI.WebControls.WebParts.PersonalizationScope</Type>
               <ToolTip>Personalization Level for this webpart?</ToolTip>
               <Default>PersonalizationScope.Shared</Default>
            </Literal>           
            <Literal>
               <ID>browsable</ID>
               <Type>System.Boolean</Type>
               <ToolTip>Is this webpart browsable?</ToolTip>
               <Default>true</Default>
            </Literal>           
     <Literal>
               <ID>description</ID>
               <ToolTip>The description for this webpart.</ToolTip>
               <Default>My Description</Default>
            </Literal>
            <Literal>
               <ID>defaultValue</ID>
               <ToolTip>The default value for this property.</ToolTip>
               <Default></Default>
            </Literal>
     <Literal>
               <ID>category</ID>
               <ToolTip>The category to display for this webpart in the webpart editor.</ToolTip>
               <Default>My Category</Default>
            </Literal>
     <Literal>
               <ID>friendlyName</ID>
               <ToolTip>The friendly name to display for this webpart.</ToolTip>
               <Default>My Friendly Name</Default>
            </Literal>
         </Declarations>
         <Code Language="csharp"><![CDATA[
private $type$ $property$;

[Personalizable($personalizable$)]
[WebBrowsable($browsable$)]
[Description("$description$")]
[DefaultValue("$defaultValue$")]
[Category("$category$")]
[FriendlyName("$friendlyName$")]
public $type$ $property$
{
 get { return $field$; }
 set { $field$ = value; }
}
$end$]]>
         </Code>
      </Snippet>
   </CodeSnippet>
</CodeSnippets>

*** Please Note that this is done on a "publishing" site, it may be that this issue (I mean 'feature') does not occur on other types of sites. But I doubt it.
 
For those of you unfamiliar with Sharepoint, it combines Master Pages (for overarching look and feel or every page in the site) with Page Templates (which help define how a specific page should be layed out but not the content itself). One way to think of it is that each page in Sharepoint has three levels:

1. The master page is the highest level and applies to all pages (unless overriden by a page or subsite)
2. The page template layout determines what 'type' of page (ie web parts page, or article page, or welcome page, or ...)
3. The actual page content.

Remeber that Master Pages can have parent Master Pages. Page Template Layouts are not considered Master Pages by Sharepoint, but for those of you familiar with the concept of parent/child Master Pages, Page Template Layouts act in the manner similar to a Child Master Page. 

Using Page Template Layouts works wonderfully on Sharepoint unless you have ...

• more than one server, or ...
• at least one extension to the server, or ...
• you move to a new server, or ...
• you move files from one server to another (via publishing, Sharepoint Designer, manual, etc).

In other words, unless you have a single url to use which never, ever changes, you may be in for trouble.
 
Why? Well it's all relative. Or more specifically it is NOT relative, it is absolute.
 
Basically whenever you create a page it prepends the page layout template section with the URL that you created the page on, turning it into an absolute reference. In other words if you take a look at your page (ex by downloading a copy) you will find that there is a section that reads like this:
 
<mso:CustomDocumentProperties>
... stuff here
<mso:PublishingPageLayout msdt:dt="string">http://theurlthatyouused/_catalogs/masterpage/PageFromDocLayout, Article page with body only</mso:PublishingPageLayout>
... more stuff here
</mso:CustomDocumentProperties>
 
Note that it has prepended the url, whether it be interal - http://myserver:8080 - or external one - http://www.myfriedmind.com.
 
So what does this mean for you? I have good news and bad news.

• The good news: even if the URL of the page is different (eg calling the page from http://myserver:9090 and not http://myserver:8080 if you extended your site) the page will still show up. Even though the absolute url is different it still pulls it from the database as if it was a relative url. Strange but true.
• The bad news: You will not be able to edit the page settings from other than the original URL.

If you do, expect this to appear:

 
WHA????????????? Where did that come from? Did someone else modify it? Nope.
 
After choosing Exit Without Saving you might get it to work. Maybe.
 
You might also get this error if you have a webpartpage and decide to edit one of the webparts. Keep clicking on choices until one of them works...
 
Does this remind anyone of being lost in the caverns of Adventures of Zelda? You are in a maze of twisty little passages, all alike...
 
The best is if you try to modify the Page Settings on such a page...

*BOOM*

What has happened is that Sharepoint is looking at the PageTemplateLayout property of the page (which is an absolute reference). If the Server Name and/or Port that you are editing from do not match that exactly then Sharepoint assumes that someone has modified the page between when you started editing and when you try to save it.

Again, one of the ways that Sharepoint tries to determine if your copy is 'dirty' (ie someone has made a change between when you first tried to edit and now) is that it looks at the PageTemplateLayout property. If there is not an exact match it rejects it. If you try to modify the Page Settings it explodes.

• Scenario #1 - you copy a page from a different URL using Sharepoint Designer - it simply copies the file, including the now INCORRECT URL.
• Scenario #2 - You are moving your sharepoint to a bigger, faster server (or you are restoring). The new server has a different name...
• Scenario #3 - You are publishing the pages out to a different front end server but want to be able to edit it from there...
• Scenario #4 - you are extending a web app to be used on the internet, and you want both internal and external people to be able to edit the same pages, but using different URLs...

etc, etc, etc...
 
What is the solution? Well, there are a couple. One is to use this nifty addition to STSADM - http://stsadm.blogspot.com/2007/08/fix-publishing-pages-page-layout-url.html. Gentleman Gary has done a wonderful job creating a flexible way to repair these beasties. The only caveat - it is an incomplete fix. Basically it still uses an absolute URL, it just replaces the wrong one with the correct one (see his note at the bottom in response to my question). It will fix #1 and #2 above (although if you move it again you will have to rerun it again), but it does nothing for #4. I am not sure about #3 <g>.

Again, note that this does not fix the issue with multiple access, only where a page has been moved. However, if it is simply a matter that you have moved your pages to a different server than this is a pretty rocking solution.
 
I have to deal with #4 after doing #2, so what do I do?

Initially I personally download each file as I uncovered the issue and manually removed the absolute url from the text and replaced it with a relative url and then uploaded the file. I expected a handful to show up, but the number kept increasing. In addition it was a pain for our staff. Sometimes I could spot it after they had made a non-blowing up modification by checking the nvarchar14 in the content database (Select tp_id, nvarchar14 from AllUserData Where nvarchar14 LIKE 'http://%') , but sometimes I would only catch if when they called me to complain.

Btw, if you are thinking that you can just modify the nvarchar14 instead of extracting and modifying the page, it does not work. It will be overwritten once another change is made to put it back to the absolute url. Trust me.

My solution ultimately was to write some code in c# that:

1. extracted each page
2. checked it out
3. inspected the PageTemplateLayout text for an absolute URL
4. replaced it with a relative URL if that was the case
5. uploaded the page
6. checked in the page
7. published the page
8. approved the page

Long term? Microsoft???? 

Maybe this is part of the design, or maybe they just missed this. I am just hoping they will fix it. There appears to be absolutely no loss of functionality with a relative reference and even thought there *might* be a case where a page template is housed on another site (and hence a different URL) this is far too serious an issue to sweep under the carpet.
 
I will enter more on another PageTemplate issue in another blog...

Recently someone asked about using Ajax on Sharepoint. I should note that a number of resources are out there on this which I used, so - as brilliant as I am <g> - the credit for this has to go to those who have gone before...

Like a lot of people I have been working on both since their betas, so whether or not I should install Ajax on Sharepoint was a no-brainer. Unfortunately, when Sharepoint 2007 first came out it was the very end of 2006 and Ajax was not officially released until January 23, 2007. As a result, in order to utilize Ajax on Sharepoint (pre-SP1) you needed to jump through a whole host of hoops. This is not to say it could not be done, merely that it was a cumbersome and painful process.

Step 1: Install SP1 on Sharepoint

Luckily the folks on the Sharepoint team made that a priority, and even though we had to wait a bit for it, they did include 'Ajax support' in SP1. So the first step to using Ajax on Sharepoint 2007 is, quite simply, install Sharepoint 2007 SP1. You can do it without SP1, but really, why would you?

Note that simply installing SP1 does not automatically turn on Ajax (there are more steps) but it removes some of the bugs that popped up.

Step 2: (Recommended): Install Asp.Net framework 3.5 SP1

The next thing that I strongly suggest is that you upgrade to .Net 3.5 (sp1). Why? Simply because if you are going to be doing any Ajax you will want to.

• It includes it directly in the framework, no need to install it separately
• It has awesome debugging - you will still use Fiddler, but less often
• Intellisense
• Much, much easier means of creating a 'tracking history' of Ajax calls

If you decide to install .Net 3.5, note that you will not see a Web Service Extension for it in the IIS Manager. This is not a flaw, this is because 3.5 is an extension of 2.0. Let me state that again - if you install 3.5 you will actually use 2.0 as the .Net version.

Doing these two steps does not mean that Ajax is automatically up and running, just that the necessary dlls have been put into the GAC.

One final note - if you install 3.5 you will be using version 3.5.0.0 of System.Web.UI.* in a number of your web.config entries. If you are using an earlier version, make sure to check the GAC and find out what the specific version is. Most of the rest of the steps involve modifying your web.config, so make sure you know your System.Web.UI.Extensions version before you being

Step 2a: Make a back up of your web.config

We are all good techies here, right? Which means we are all paranoid, right? Never, ever modify your web.config unless you have a rollback copy at hand. Remember, paranoia is a job-requirement.

Step 3: Add the system.web.extensions sectionGroups to the configSections of your web.config

If you are not familiar with Sharepoint, this will be located in your c:\inetpub\wwwroot\VirtualDirectories\wss\{your site's port here}. So if you have your Sharepoint on port 8080 your web.config will be located at c:\inetpub\wwwroot\VirtualDirectories\wss\8080. Remember to make a copy of it like a good, paranoid nerd. Also, I tend to remark what I am adding and why to my web.config, but you don't have to.

Add this in the <configSections> portion, which should be at the top. You will already see other <sectionGroup... > entries there, just add this one at the end (above the </configSections> entry), wrapped for readability...

Step 4: Add System.Web.Extensions as a "SafeControl" to your web.config

SafeControls are those assemblies that should be considered "Safe" by Sharepoint. Do a quick find for <SafeControls> and you will see a whole lotta them. Simply add this line to the bottom, above the </SafeControls>.

NOTE!!! If you are using a different version than .net 3.5, make sure that you verify what version it is in the GAC. This needs to be specified in the "Version" section or Sharepoint will throw an error. Because I am using 3.5, my version is 3.5.0.0

Step 5: Add the needed "verbs" to your <httpHandlers>

Note that this is NOT the <httpModules> section. There should already be some entries there, so just stick this at the end, above the </httpHandlers> line....

Step 6: Add the <controls> reference to the <pages...> section of the web.config

This will enable your pages to recognize the controls that come with Ajax (such as the ScriptManager, etc). Locate the <pages ...> section and add this at the end above the </pages> entry. Again, keep an eye on the Version.

Step 7: Add this at the very end of your web.config, just above the </configuration> line

Of course you could stick it somewhere else, but let's be neat here... This is the section that first thing that you put into your web.config (the <sectionGroup...> referenced. There is documentation out there on sectionGroups, and they are very handy, if you get interested. I have left a lot of commented lines in there for if you need them. And, once more repeat after me, if you are not using 3.5, check the Version!

Step 8: Add a ScriptManager to your Master Page

You can always do it dynamically, and I always check in my code to see if it exists before whatever webpart I am writing loads, but it is much simpler just to add it on your Master Page. Just stick it below the <form id="Form1"... > entry :

<asp:ScriptManagerrunat="server"ID="ScriptManager1 />

Please note that there are a LOT of other goodies you can add to your ScriptManager, especially in .net 3.5, so feel free to expand it. Just make sure it is in there.

Step 9: Write Ajax pages (or webparts).

If you have followed these directions you should be ready to roll. I have not included how to add the AjaxControlToolkit, but if you are this far it is fairly a no-brainer. Add the .dll to the GAC; add the assembly reference to the web.config 'assemblies', add the namespace entry to the web.config 'controls' section and you are ready to rock! 

Final NOTE!!! UpdatePanels on Pre-SP1 ...

You may need to add the following code to get UpdatePanels to work properly, just put it in your Master Page