I was getting this error when trying to access my SSP. Then I found this terrific forum thread that made my day. Thanks Lionel!

To summarise:

 

Add the application pool account to the local admin group.
Perform an IISRESET on the SharePoint server.
Run the PSconfig wizard. Test if the issue goes away. If it does, go to Next Step.
 Remove the user back from the local admin group, perform an IISRESET again.

This is more a reminder for myself since I am ALWAYS forgetting this command. Run this on the SharePoint server under the farm account to ensure you don’t have any restricted access issues.

stsadm -o createsiteinnewdb -url http://server/sites/collection -owneremail you@sharepointadmin.com -ownerlogin testss\SPAdmin -sitetemplate sts -title “Site Collection” -databaseserver SERVERDB -databasename NewContentDB

Quick and easy- navigate to http://server/yoursite/_layouts/viewlsts.aspx?BaseType=1 There you will get a “list” of document libraries in the current site. You will notice on the RHS you have the standard list VIEW menu. You can change this to see Picture libraries, lists, etc OR you can just change the BaseType value in the URL yourself.  This ain’t real pretty and it doesn’t come wrapped up in a nice lil web part package but its not that hard to create one. I am not going to bother since I found this fabuMOSS (‘oh yes I did’) CodePlex creation which don’t just list em but allows you to explore em using a treeview menu. Shazam!

When clients request a test environment as an “after thought” to installing and configuring a production environment you’ve got to make a few decisions about how this will be done. This post will outline how I prefer to swing it and what has worked for me so far. Keep in mind though that farm size and capacity should dictate your methods. The methods I discuss here fit for a small to medium size farm.

Virtualisation

Where possible recommend setting up virtual servers to replicate the production environment. This is usually a lot cheaper and allows for a lot more flexibility. You quite often see businesses using a test environment which is a single server setup despite their production farms containing multiple servers. It is always best to try to mimic the environment completely and with virtual servers this is a bit easier as you can magically conjure a swish new server from virtually nothing ;)

Snapshot or fresh install

Fresh install definitely, although I can’t say I’ve ever tried the alternative. If the prod environment happens to be virtual too I wouldn’t recommend taking a snapshot and restoring it as a test environment. I can imagine all kinds of conflicts and issues with that and you reeeeally don’t want to jeopardize your production environment. I prefer to start from scratch and install the pre-requisites, SharePoint, services packs and updates again.

Database Servers- to share or not to share

I usually recommend sharing (remember I am talking about small to medium farms here) but that’s usually because it’s the more preferred, cheaper option. If you already have a spare SQL server sitting around, you can certainly take advantage of that. I do find it a bit of an advantage sharing with production though when it comes to troubleshooting issues. Remember we really want prod and test to be identical. When an error is occurring on the prod environment and it is also occurring on the test server you can pretty much assume the issue is occurring in a shared resource which narrows down the search somewhat. I always recommend creating a separate SQL instance for test though. That way you can keep you DB naming convention the same and it’s not confusing when trying to figure out which DBs are for prod and which are for test.

Back-end Configuration

Set your SSP and services up as you did in production although it doesn’t really matter if this is exactly the same. For example the user profile import probably doesn’t need to run quite as regularly as it does in production but then again I have been pushing the identical environment thing so you may just want to make the effort and set them up with exactly the same schedules. If you have created an “as built/installed” document previously with all this configuration detail, now is a great time to test is accuracy.

Content Database Migration

Now as you have installed SharePoint in the exact same way as in production (with all the latest updates and service packs) you can relax and know that you can add your production content databases to the test farm no problems at all. What I have found works best is to create the root web application, let’s say SharePoint-80 , in the test system and if you want, create a site collection and navigate to it to make sure all your install efforts have not been in vain and everything is working. Then backup and restore your production root web app content DB to the test instance and overwrite the root site DB with the same name. Once you’ve done this you can add the content database through the Central Admin GUI. That should be that, you should now be able to navigate to the root site and there should be all your production data. Migrate any other content databases as needed and add through GUI.

Customisation

Now this part will depend on the type of customisation you have gotten your hands dirty with. If SharePoint designer is your friend and most of your customisations have been through designer you should make pretty short work of it. These customisations will be stored in the content databases you have already migrated. Any custom web parts or features used in production will have to be migrated into the test file system (GAC/bin/hive directory). You also have to install and activate any features you whack in the hive – just because they are in there doesn’t mean the job is done. If you have wrapped up all your customisations in lovely little solutions that you must now set to work deploying those (well done SharePoint nerd). If you have been a good developer you won’t come across any nasty dependencies which dictate in which order you deploy your solutions. Lastly, if you are a bit naughty sometimes and make changes to files in the hive directory (like blog site templates etc) then you need to make sure those files have been migrated from production too. I tend to apply these customisations across all SharePoint servers in the farm even if they are not WFEs. That way, if you ever need to swap one in for a sick WFE, its easy peazy.

This is the full error you will see in your logs at the time of submission : InfoPath cannot submit the form. An error occurred while the form was being submitted. A value in the form may be used to specify the file name. If you know the value in the form that specifies the file name, revise it and try again. Otherwise, contact the author of the form template.

There are two possible causes and solutions for this error:

1) You are trying to submit a form that has already been submitted to a document library or the form you are attempting to submit has the same name as an existing form in the library. Solution – either ensure the form is being submitted with a unique name e.g. append and date time stamp to filename specified in the Submit data connection (wizard) OR check the Allow overwrite if file exists check box, so that the form can be overwritten if it already exists in the Document Library.

2) You are submitting the form to a SharePoint list instead of a form or document library. Solution – modify the Submit data connection and ensure that the Document library field contains a URL to a Document or Form Library and not a SharePoint List.

Update

I have been informed by an informer that it may also be due setting the form submit address to a form library view rather than just the library.

Also, another good post on this subject can be found here: http://claytoncobb.wordpress.com/2009/06/20/auto-generating-filenames-for-infopath-forms/

This is the niftiest post I’ve read in a long time! Paul Culmsee, you are my MOSS idol. This post is pretty much for my own selfish use. I can see myself using this “polite hack” regularly so I want to make sure I’ve got it in close proximity.

Ok so all you need to do is navigate to your list form in a browser  and append:  &ToolPaneView=2 to the URL. This will display the Add Web Part tool pane so you can add/remove web parts as you like.

Recently while developing and testing a web service which called the SharePoint lists.asmx service I consistantly received a ‘401 unathorised’ exception when calling the lists.asmx method getlistitems(..). I passed the default network credential and ran the app under the system/farm account, I created a new network credential and used service account credentials but no matter what, I always got the 401. After much frustration I found this kb article: http://support.microsoft.com/?scid=kb;en-us;896861&x=14&y=17 which fixed the issue.
 
Cause:
This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
 
Workaround:
To work around this issue, use one of the following methods.

Method 1: Specify host names

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
  3. Right-click MSV1_0, point to New, and then click Multi-String Value.
  4. Type BackConnectionHostNames, and then press ENTER.
  5. Right-click BackConnectionHostNames, and then click Modify.
  6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  7. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check

Follow these steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  3. Right-click Lsa, point to New, and then click DWORD Value.
  4. Type DisableLoopbackCheck, and then press ENTER.
  5. Right-click DisableLoopbackCheck, and then click Modify.
  6. In the Value data box, type 1, and then click OK.
  7. Quit Registry Editor, and then restart your computer

You’ll know what I’m talking about here if you have ever tried to customize the blog site template. When you create a MOSS blog site you’ll notice that the left nav bar and breadcrumbs are different to those in other standard sites, despite setting the site to use the same master page. In some cases, SharePoint just decides to override stuff in your master page and there ain’t a gosh darn thing you can do about it- using the GUI anyway. You can however, modify the site template files to better suit you and use the same nav as your master page. This is a bit of a no no because you will be modifying files in the hive directory, so if you want to be all “best practice” about it, you should copy the blog site template and create your own custom template to use instead.

Anyway, for the purpose of this post I will talk you through modifying the hive files.  On your WFE/s server navigate to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\Blog

Backup and edit the default.aspx page. Replace:

<asp:Content ContentPlaceHolderId=”PlaceHolderTitleBreadcrumb” runat=”server”/>

 

and

 

<asp:Content ContentPlaceHolderId=”PlaceHolderLeftNavBar” runat=”server”>

                <div class=”ms-BlogNavigator”>

                <div class=”ms-quicklaunchouter”> <div class=”ms-quickLaunch” style=”width:100%”>

                <Sharepoint:SPSecurityTrimmedControl runat=”server” PermissionsString=”ViewFormPages, ManageLists”>

                                <div class=”ms-quicklaunchheader”><SharePoint:SPLinkButton id=”idNavLinkViewAll” runat=”server” NavigateUrl=”~site/_layouts/viewlsts.aspx” Text=”<%$Resources:wss,quiklnch_allcontent%>” AccessKey=”<%$Resources:wss,quiklnch_allcontent_AK%>”/></div>

                </SharePoint:SPSecurityTrimmedControl>

                                <WebPartPages:WebPartZone runat=”server” FrameType=”TitleBarOnly” ID=”BlogNavigator” Title=”loc:BlogNavigator” />

                <div id=”BlogRSSNav”></div>

                </div></div>

                </div>

</asp:Content>

 

With asp:Content tags containing your desired controls (cut and paste from your master page if need be) e.g.

 

<asp:Content ContentPlaceHolderid=”PlaceHolderTitleBreadcrumb” runat=”server”>

<div class=”breadcrumb”>

You are here:

<asp:SiteMapPath ID=”siteMapPath” Runat=”server” SiteMapProvider=”CurrentNavSiteMapProviderNoEncode” RenderCurrentNodeAsLink=”false” CurrentNodeStyle-CssClass=”breadcrumbCurrent” NodeStyle-CssClass=”ms-sitemapdirectional” CssClass=”body”/>

</div>

</asp:Content>

 

Now in the case of the blog site template it gets a bit more complicated because there are several pages used when creating posts and categories etc so you have to update these files in the same way. These pages are stored in the template’s Lists folder C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\Blog\Lists

Most SharePoint users would be familiar with the built in WEBDAV functionality; like document library explorer views which allows drag and drop functionality or the ability to map a document library in SharePoint as a network drive but  most don’t  consider that a combination of this SharePoint and NTFS functionality can provide a really cool web interface to a file system.  Here is an example so you can see what I mean..

Create a very basic SharePoint site collection called Company. Keep it as sparse as possible so WSS style, no publishing, etc. If you wanted to you could delete any of the document libraries and lists created automatically with the site collection template so there is basically nothing in the site. Next, create a sub site called IT, again keep it minimal (use a blank site template) but make sure a document library is available to house your file system docs.

Download SPIEFolder from codeplex. This is a great little cmd line tool that is so simple that it just can’t go wrong. I’ve heard of all kinds of utilities that have been produced to migrate documents from a file system to SharePoint -with fancy bells and whistles that let you maintain the NTFS security and exclude ceratin file types etc but from what I have seen, the fancier the utility the more likely it is going to fall over and not recover, which is not cool when you want to leave it running over night to migrate 1000s of documents. SPIEFolder is great and the source code is provided so if you want to, you can add in some extra functionality yourself (e.g. a bad filename renamer function- I’ll release this later).

Set this lil guy migrating a small folder in your file system to the IT document library.

spiefolder http://sharepoint/company/IT  ”Procedures” c:\spiefolder\SeedFiles import

When the migration is complete, map the company SITE as a network drive by opening explorer, chosing Map network drive and entering the site address e.g.  \\sharepoint\Company under the relevant drive letter. Now you should be able to see the entities inside your SharePoint site. Some of these are not visible through the GUI but are visible in explorer such as the m folder which represents the mobile features of the site.

company1

In your company drive, all you really want to see is your IT site so you can navigate into the directory and consequently see your IT ”Procedures” library. What you need to do is use explorer to right click the folder you want to hide, select properties and then tick the hidden box at the bottom of the properties window. Hide everything but your IT folder then open the folder and you should see you Procedures library.

hidefolder

When you open the library folder you will see the documents inside. SPIEFolder will create folders inside document libraries based on the file system structure you are importing from. If you have very complex item level permissions in your file system you may want to look at another tool other than SPIEFolder because with this tool permissions are not bought across. You can however replicate the permissions in SharePoint using the GUI and this access will be applied in the explorer window also.

There is a bit of fiddling in the beginning to import each FS folder strcture into the relevant site and document library in SharePoint and hide any unwanted entirties in explorer, but after that you are left with a really neat representation of your file system within SharePoint. Things to consider here  are the size of the document stores you will be migrating. Consider the final size of your content database and perhaps think about moving “departments” or other categories of documents into separate site collections with differnt content databases.

In this case I am using the viewswitched event captured in the form “code behind” but this means I had to publish the form as an Administrator-approved template and upload it into Central Admin.  There are a few ways to code this but here I am using the SharePoint object model. I use the RunWithElevatedPrivileges call to execute the code under the application pool account. This is relevant because I am allowing annonymous users to “submit” the form to SharePoint.

public void FormEvents_ViewSwitched(object sender, ViewSwitchedEventArgs e)
        {
        SPSecurity.RunWithElevatedPrivileges(delegate() {

         EventLog _eventLog;
            _eventLog = new EventLog(“Application”);
            _eventLog.Source = “InfoPath Form Upload”;

               
            XPathNavigator xPathNav = MainDataSource.CreateNavigator();
            string name = xPathNav.SelectSingleNode(“/my:MessageSection/my:hiddenName”, NamespaceManager).InnerXml;
             string webappurl = this.Template.Uri.ToString().Remove(0, 7);
            webappurl = webappurl.Split(‘/’)[0];
           string url = “http://” + webappurl + “/FormLibrary/” + name + “.xml”;                   

            System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding();

           byte[] Data = encoding.GetBytes(xPathNav.OuterXml);

            try
            {

                 SPSite mySiteCollection = new SPSite(http://sitecollurl);
                SPWeb myWeb = mySiteCollection.RootWeb;    
                SPFolder doclib = myWeb.Folders["Form Library"];
                SPFile file = doclib.Files.Add(doclib.Url + “/” +
                      name + “.xml”, Data, true);
                doclib.Update();
            }

            catch (Exception ex)
            {
                _eventLog.WriteEntry(“Form Upload Failed ” + ex.Message);
            }
        });
        }

Next Page »