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:
September 17, 2009
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:
September 17, 2009
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
September 16, 2009
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!
May 18, 2009
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.
May 15, 2009
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/
April 14, 2009
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:
Follow these steps:
April 1, 2009
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.

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.

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.
March 26, 2009
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);
}
});
}