stsadm -o setformsserviceproperty

 -pn <option name>

 -pv <option value>

Option Names:

DefaultDataConnectionTimeout

MaxDataConnectionTimeout

MaxDataConnectionResponseSize

RequireSslForDataConnections

AllowEmbeddedSqlForDataConnections

AllowUdcAuthenticationForDataConnections

AllowUserFormCrossDomainDataConnections

AllowUserFormBrowserEnabling

AllowUserFormBrowserRendering

AllowViewState

ViewStateThreshold

ShowProgressRolesManager

AllowBranding

Example - to turn off the "Powered by Forms Services" logo on your form services forms:

stsadm -o setformsserviceproperty -pn AllowBranding -pv false

Note: You can use stsadm -o getformsserviceproperty -pn to see what the default values are for that particular property

For a full list of the stsadm commands go to: https://webservicecatalog.com/post/STSAdm-Command-line-Guide.aspx 

Document Library fields

 Custom list fields 

In addition to a number of changes made to reduce the load time discussed elsewhere, it was decided to improve the user experience by adding a Pre-Loader to give the user some feedback while the form is loading.

Here is how this was done in C# (feedback appreciated - particularly if you know of a better way to do this):

     0. Add a reference to System.Drawing and then add the following using statements at the top of the FormCode.cs file (there may be others):

            using System.Drawing;

            using System.Diagnostics;

            using System.Threading;

1.  Add the following using statement at the top of the FormCode.Designer.cs (click on "Show All Files" if you don't see this file under the FormCode.cs file)

              using System.Windows.Forms

          Declare the preLoaderForm at the top of  FormCode.Designer.cs* under the "internal Microsoft.Office.InfoPath.Application    Application;" and "internal Microsoft.Office.InfoPath.EventManager EventManager;" declarations:

           internal Form preloaderForm = null;

2. Add inside the FormCode constructor in the FormCode.Designer.cs*

LaunchPreLoader();

3. Add two new methods to FormCode.cs

        private void LaunchPreLoader()

        {

            try

            {

                System.Threading.Thread newThread = new System.Threading.Thread(new System.Threading.ThreadStart(this.Preloader));

                newThread.Start();

            }

            catch

            {

                // do nothing

            }

        }

        private void Preloader()

        {

            try

            {

                preloaderForm = new Form();

                preloaderForm.Text = "Form Loading";

                preloaderForm.Size = new System.Drawing.Size(250, 75);

                preloaderForm.Location = new System.Drawing.Point(400, 200);

                preloaderForm.StartPosition = FormStartPosition.CenterScreen;

                Label message = new Label();

                message.Text = "Your form is loading";

                message.Location = new System.Drawing.Point(20, 8);

                message.Size = new System.Drawing.Size(200, 15);

                Panel progBarPanel = new Panel();

                progBarPanel.Width = 250;

                progBarPanel.Height = 50;

                progBarPanel.BackColor = Color.Gainsboro;

                ProgressBar progBar = new ProgressBar();

                progBar.Location = new System.Drawing.Point(20, 20);

                progBar.Style = ProgressBarStyle.Marquee;

                progBar.MarqueeAnimationSpeed = 250;

                progBar.BackColor = Color.DodgerBlue;

                progBar.Size = new System.Drawing.Size(200, 15);

                progBarPanel.Controls.Add(message);

                progBarPanel.Controls.Add(progBar);

                preloaderForm.Controls.Add(progBarPanel);

                preloaderForm.ShowDialog();

            }

            catch

            {

                // do nothing if preloader fails

            }

        }

4. To close the pre-loader, add the following code to the bottom of the FormEvents_Loading method in FormCode.cs. If you don't see a FormEvents_Loading method in your FormCode.cs file, then in InfoPath go to Tools > Programming > Loading Event - and it will be generated for you.

If( preloaderForm != null )

            {

                        preloaderForm.DialogResult = DialogResult.Yes;

}

*Note that steps 1 and 2 are in the FormCode.Designer.cs file. It is not advisable to make changes to this file since it is autogenerated and your changes can be easily lost. But on the onther hand, the Pre-Loader is only useful if it opens early enough, and the FormCode constructor is the earliest point we can get to in the FormCode class. If you cannot deal with the maintenance issue when this code is autogenerated (re-adding the three lines of code in steps 1 and 2) then you can try locating this code in FormCode.cs and see if it runs early enough to be useful to you.

          C:\Documents and Settings\[User]\Local Settings\Application Data\Microsoft\InfoPath\FormCache2

When a new version of the form is detected, such as when a new version of the form is installed in a SharePoint Forms library, the cached form will be deleted and the new one installed in it's place.

You can also manually clear the Infopath cache by deleting the files.

Or you can do it via command line by:

            Start > run > Infopath /cache clearall

But MOSS Variations does not fully function (unless the issue has been fixed in recent hotfix that I missed) with custom content types unless those content types are in the site definition of the publishing sites themselves.

In other words, creating custom content types and deploying them as features is not enough. You currently need to create custom site definitions incorporating the custom content types – otherwise the pages are not replicated correctly using variations.

Unless you are going to use the OOB publishing site definition with the OOB publishing page layouts, then your process of creating a WCM (Web Content Management) site using Variations has to be frontloaded with nailing down the Content Types and generating Site Definitions:

·         first develop the master pages, content types, layout pages, get a fully working site that does what the customer needs

·         then create/generate site definitions that include those content types and layout pages etc.

·         then setup the authoring site using the custom site definitions - enabling Variations and adding the required Labels

If you are in a situation where the everything needs to happen at once - where the authoring team needs to enter content as the development team is developing the WCM site, then you may have to work around this issue:

See https://blogs.msdn.com/michael_yeager/archive/2008/05/08/variations-without-custom-site-definitions.aspx

1.       The intention to use the Content Query Web Part (CQWP) to roll up lower level detail pages to higher level summary pages can have a major effect on your “Content Type Architecture” The CQWP has the ability to query across multiple sites by  Content Type. In a “catalog” style site where one is drilling down to detail pages, the ability to roll up across many different Pages libraries by Content Type can be a crucial functional detail

2.       Another important detail is the fact that a content type can have many layout pages. Often the authoring team wants to be able to switch between layout pages for the same content. You can do that by simply making sure the layout pages share the same content type, and that the fields that each layout page shares line up properly.

The first issue encourages the site architect to create more content types to make it easier to roll-up the content. The second issue encourages the site architect to create fewer content types each having multiple layout pages so that the authoring team can easily switch between layouts.

The reason for this is that when Variations creates a new site or sub-site, it uses the Site Definition that was used for the original root site. So if you created the original root site using the Publishing Site Definition with it's standard welcome page, your new variation will be created with that Site Definition. But then there are two problems. The Pages library is not enabled for any of your custom content types. And probably you created a new welcome page with a custom layout page built on a custom content type, and the one created by Variations will be the OOB welcome page. Thus errors are thrown, pages show up blank, no content appears to be propagated.

Again, the preferred process with a new Publishing/Variations site is to build out an initial version of the new site. Define all the content types in the UI, create layout pages in SharePoint Designer based on those content types. Then have your users use it, provide feedback, and do as many iterations until everything is just right, and then turn around and build the custom site definitions with your now perfectly designed content types.

But a recent client of mine could not possibly do this. Because the site had to be up on such and such a date, there wasn't time to build custom site definitions much less have the custom content types completely defined in advance.

We built the site, it went live on time, and then after the fact I tried to figure out if I could get Variations to still work.

And what I found is that:

1. When you create a new Label, set Hierarchy Creation to create the "Publishing Sites Only" - no pages
2. After the sites have been created, rename the old welcome page (to default2.aspx for instance)
3. Then make a change on the home page of the site so that a new version will propagate (this appears to both add the custom content type to the Pages library, and add the custom page)
4. After propagation, go and delete the old welcome page out of the library (may need to repoint the Welcome Page to your new page first)
5. Now all other pages within that site will propagate correctly
6. repeat for each site in the site site collection

Only just at the beginning of testing this work around, but so far everything appears to work fine.

Unfortunately one has to do this every time a new site is added, but then -- hopefully there will be a fix for this whole issue coming before too long...

The main thing is to first install SP1 and KBs 941422, 948945 and 950279, and 952698 and 952704  (these last two may rollup all the changes in the earlier KBs, I am trying to confirm that).

Beyond that, the best information on debugging Content Deployment jobs can be found on Maxime Bombardier's blog:

 https://blogs.msdn.com/maximeb/archive/2008/02/19/debugging-content-deployment-issues.aspx

(setting versioning to only Major Versions in the Style Library helped me out big time)

 and in parts 5 and 6 of Stefan Goßner's series on content deployment: 

 https://blogs.technet.com/stefan_gossner/archive/2007/10/12/deep-dive-into-the-sharepoint-content-deployment-and-migration-api-part-5.aspx

Also note that there are quite a few fixes included in SP1 plus the post SP1 rollups KBs 941422 and 948945 and 950279.

https://support.microsoft.com/kb/941274

https://support.microsoft.com/kb/948945

https://support.microsoft.com/kb/950279

There are two KBs that are specific to Content Deployment with 60+ fixes. If you have having serious CD problems, you'll need to talk with Customer Support Services to obtain these:

https://support.microsoft.com/kb/952698 

https://support.microsoft.com/kb/952704/

In theory these two are a rollup of all the previous Content Deployment hogfixes. I am still trying to confirm that this is true.

Mostly I'm talking about Master Pages and Layout Pages - which you can check-in and check-out in your browser by navigating to the Master Pages Gallery found under Site Settings > Galleries > Master pages and page layouts

Also, I typically use the Publish Selected Files functionality to promote new Master Pages and Page Layouts from Dev to Production, but note that you have to check out the files on both servers. The easiest and most effective way to do this again is in the browser by navigating to the respective Galleries on each farm and checking them out in the browser.

For instance, you go to the Master pages and layouts Gallery on production and check-out your custom master page, and you go to the Master pages and layouts Gallery on development and you check-out your custom master page, and then on Dev in SharePoint Designer you right click on your custom master page and select Publish Selected Files (and enter the url for your production site if you haven't already).

Note that after you Publish your new versions, they are only minor versions, and you can view them on production without endangering the site for other users. Once you confirm that they are working and doing what you want, then you can Check them in as a Full version on production. Remember also then to Undo Checkout on Dev. You only checked it out to publish it, so just Undo Checkout so that you don't have a new insignificant version.

To review - after Publishing, on Production after checking them as a Minro Version you check in and approve a Major Version, and then on Development you Undo Checkout.

A little complicated, but it works consistently.

This is a tough one - just navigate to: https://<yoursite>/Style Library