In this post, I outlined how to create expandable/collapsable regions in InfoPath 2007 or InfoPath 2010. This technique works in either one. Basically, if you follow the step by step guide, you’ll be able to create this:

Collapsed

Expanded

Give it a try and let me know if you run into any issues. If anyone is having trouble translating this for InfoPath 2007, leave a comment and I’ll create a 2007 version of this post. The original solution was developed using InfoPath 2007, so it definitely does work.

I’m going to share some notes and some testing I’ve done with the various settings, this should give everyone a basic idea of how it works and what to expect.

1. Before OWA is installed, Word, PowerPoint and OneNote applications will always prompt to open in the client. If the user does not have the client installed, they won’t be able to make any edits or open the document. I haven’t included Excel in this mix because depending on wether or not Excel Services is configured, this may or may not be true. Remember, we’ve had Excel Services long before 2010 and OWA came along.
2. Whenever I do this type of installation in a client environment, this is the guide I follow: http://technet.microsoft.com/en-us/library/ff431687.aspx. It’s well written and includes just above everything I need.
3. There’s an important bit of information in that guide and something you must take note of. Office Web Applications tightly integrates with SharePoint. Once you do the installation, the default behaviour for opening documents will be changed. I’m going to outline these defaults below, but as a general rule of thumb, you should consider enabling the OpenInClient feature at the Site Collection level BEFORE installation. This will ensure that files default to opening in the client, and not the browser, until you can get it all configured. I’ll explain why this is important in my screenshots below. See more details here: http://technet.microsoft.com/en-us/library/ee837425.aspx.

When Office Web Apps is first installed, services are started, service applications are created – however, feature is yet not activated.

Now what you’ll notice is that, instead of opening in the client, as was the case prior to the installation of Office Web Apps, the document will open in the browser as you can see in the below screenshot.

If we attempt to click on Edit in Browser, we’ll be presented with an error message like the one below because the Office Web Apps feature has not yet been activated on this Site Collection.

After activating the OpenInClient default.

Now that we’ve activated this feature, our default will be to open all files in the client. In other words, we’ve set OpenInClient to true. This will prevent errors like the one we saw above. This is why it’s recommended that this setting be enabled before OWA is installed, so that you don’t impact your users until you are ready to start the services, create the service applications and activate the necessary features.

After activating the Office Web Apps feature.

If we activate the Office Web Apps feature, then we can edit our Word documents inside of the browser.

Changing the behaviour for a specialized document library.

Now that we’ve enabled Office Web Apps at the Site Collection level, we may want to enforce that some libraries only OpenInClient by default. The default is usually Use the server default (Open in the browser).

This will force documents, by default, to open in the client as opposed to the browser, regardless of what the setting is at the Site Collection level.

Scenario

Let’s assume we have a Date Received column. After 2 weeks of initial item creation, we want to send a reminder notification to the user. So based on the value of Date Received column, add 14 days, and if Today matches that value, then send a notification. For this we need the Pause Until Date activity, so we do a quick evaluation, if there is a match, send the reminder, otherwise, pause until we reach that date.

1. User enters Jan 13, 2012 in date received and creates new item.
2. Workflow kicks off and determines that Jan 13, 2012 + 14 days is equal to Jan 27, 2012.
3. Workflow checks if Today is equal to Jan 27, 2012. If it is, send the email reminder.
4. If it isn’t, Pause Until Jan 27, 2012. You will see the pause activity log to the workflow history list the day it’s planning to pause until.

Perfect right, works great. Now what happens when a user edits the item and changes the date received to Jan 17, 2012. We want the delay to postpone until the 31st of Jan, not the 27th. I’ve read a great deal of posts that document how others have tackled this problem, ranging from an event handler to some sort of custom workflow logic. In our case, since the forms were custom ASP.NET forms submitting programmatically to the list, it was easy enough for me to track any changes to the date received column, and if I do find that it has changed, I simply stop and restart the workflow within the submit event. The logic looks like this:

// stop and restart the workflow if date received is different
if (dtcDateReceived.SelectedDate.ToShortDateString() != dateReceived.Value)
{
    // stop workflow
    SPWorkflowCollection itemWorkflowCollection= item.Workflows;
 
    SPWorkflowAssociation workflowAss = yearEnd.WorkflowAssociations[new Guid("369dcef7-b35c-48f1-bf2f-5b9f53d568ee")];
 
    foreach (SPWorkflow itemWorkflow in itemWorkflowCollection)
    {
        if (itemWorkflow.ParentAssociation.Id == workflowAss.Id && (itemWorkflow.InternalState & SPWorkflowState.Running) == SPWorkflowState.Running)
        {
            SPWorkflowManager.CancelWorkflow(itemWorkflow);
            site.WorkflowManager.StartWorkflow(item, workflowAss, workflowAss.AssociationData);
            break;
        }
    }
}

For completeness, this is how I set the hidden field on load that stores the original Date Received value.

// set date received to see if it changes
 dateReceived.Value = Convert.ToDateTime(yearEndItem["Date Received"]).ToShortDateString();

Thanks Tony for the original post that helped me build out the logic above:

http://www.tonytestasworld.com/post/Howto-Start-a-Sharepoint-Workflow-Programmatically.aspx

Hey Shereen, Why don’t you use InfoPath more often in your projects?

To which I often reply, it’s the 80/20 rule. InfoPath doesn’t get me all the way there, and to invest that much time and effort only to hit some project impeding roadblocks is not a conversation I like to have with our clients. It’s not fun, no one enjoys explaining why you CAN’T do something, because when it all boils down, clients are only interested in the solution.

Recently, however, I was given the opportunity to work with InfoPath again, and it’s reminded me in many ways, the pros and cons of using this tool. So I’ve jotted some notes down, and I’ll share with the rest of you, and if we can have a constructive, intelligent debate about this, I’m all for it. Keep in mind this is InfoPath 2007.

Let’s start with the Pros.

1. It’s incredibly easy to do some basics in InfoPath. Adding controls to a page, validating those controls. Applying conditions that define when to show/hide specific content, or when to display that content in a different way. Tab order, submission and layout are all examples of things we can do well in InfoPath. This is something any power user can do, and probably do well.
2. It makes it possible for power users to maintain a form post-development and well into the future. The same is not true for a custom form or web part built in ASP.NET I don’t care how ‘powerful‘ your users think they are.
3. It’s definitely a bit easier to deal with Lookup columns and People or Group columns in the sense that it takes very little effort to wire them up and save/load from those controls within InfoPath. These are often problematic in standard ASP.NET form development.
4. Repeating tables are great, these take little to no effort to add to the page and give users a lot of flexibility so that they may dynamically add or remove additional rows.

So definitely some good things we can do with InfoPath, however, there are definitely some pitfalls that make you go ‘ARRGHHHH‘!

1. You can’t use a Contact Selector field and publish to a column of type Person or Group, you have to use either a workflow to populate these fields or custom code. A lot of times, we use these fields to power views with the [Me] keyword to display personalized views of the data. This is hard to do when a Contact Selector translates to a Single Line of Text. It also starts to challenge the Ease Of Administration principle I talked about above, because now users have to maintain a workflow or a section of custom code to get past this hurdle.
2. In terms of order and organization of the Data Sources, it sucks. Any field that you create and then remove, does not get removed from the data source (which I understand), and you have to manually manage and maintain your data sources to keep it clean. I can honestly waste a ton of time formatting and moving fields into the appropriate containers and ensuring that overall, the data source stays clean. Maybe I’m just being anal, but it’s not something I particularly enjoy – I do feel it’s necessary though. It can get pretty hard to read if you have a form with 100 fields and you let it get out of control.
3. It’s not easy adding expandable/collapsable regions. If you don’t agree, let’s throw up a challenge where you build out your regions in InfoPath and I’ll do it in html/css/jQuery and we’ll see who finishes first.
4. Repeating tables only save the first row of data, not subsequent rows. So anytime you do use a repeating table, don’t plan on using that information for any views or filters of any kind. Normally though, this isn’t something I find myself needing to do often, but when it does come up, it’s kind of a pain that I can’t do it.
5. Rich text formatting is not supported in browser based forms.
6. There is no way that I know of to add a header and footer. If you’ve got a header or footer and multiple views, any change to those will have to be applied to each view. I’m not positive about this one, but if anyone corrects me on this, I’d be happy to update this post.
7. If you are using any code in your InfoPath forms, you have to be careful with inconsistent or unsupported behaviour between the InfoPath client and browser enabled forms.
8. March 30, 2012 – If you need to make changes to the name of a field in your InfoPath form, it more often than not, results in a loss of data for that particular field (if it’s being promoted as a column in SharePoint).

Tips

1. When setting up tabbing between sections, it’s wise to setup a break in numbers in case it changes down the road. Otherwise imagine defining your tabbing order and then inserting a field at tab order 10.

So to summarize, I definitely see the power of InfoPath and if I can keep the requirements dead simple, and there’s flexibility when we hit roadblocks, I don’t see why this wouldn’t be the faster approach to form development. I’d probably recommend it.

However, if the reverse is true, and I know there will be business workflow or requirements that will make working with InfoPath a challenge, I’ll opt for the custom web form route, because that guarantees me no limitations to what I can do. And it’s likely faster.

It all comes down to an evaluation of the requirements and the prioritization of features over simplicity and maintainability that will ultimately guide which route I take.

If anyone would like to add to this, or has a suggestion for something I overlooked, ping me here or send me a tweet on twitter. I’m all for finding better and more efficient ways for getting things done.

My initial research into this issue let me to the following blog: http://fastforum.info/viewtopic.php?f=6&t=223.

Basically the users commenting in this thread talk about an inconsistency between the Install_Info.txt file and the ContentDistributor.cfg file in terms of the port number which is set to 13390. It was always odd to me that the Install_Info.txt and ContentDistributor.cfg file were not consistent and many believe this to be incorrect.

The change that you would make would be an update to the FAST Search Connector in Central Admin, so that the port number reflects what’s in the ContentDistributor.cfg file. While this may work temporarily, this is INCORRECT!

The port for the Content Distributor should be AS IS reflected in the Install_Info.txt file. So 13391 if you stuck with the defaults.

Read the following from a KB article from MS:

The “Fast Connector SSA” may be incorrectly configured to use port 13390. The %FASTSEARCH%\install_info.txt” displays the Content Distributors with port “13391″, however the %FASTSEARCH%\etc\contentdistributor.cfg” displays port 13390. If the portfor the “Content Distributors” in the “Fast Connector SSA” was configured as “13390″, connectivity to FAST will fail. If this is the case, the “Content Distributors” in the “Fast Connector SSA” should be reconfigured to use port 13391 as stated in the install_info.txt.

We’re particularly eager this year because we’ve been working hard on the launch of our SharePoint line of add-ons: www.blackninjaparts.com. We’ve officially gone live today, just in time for SP Conf and we’ve got some super awesome t-shirts to give away throughout the week. You’ll see a few of us wearing them, so don’t hesitate to stop us anytime and grab yourself one before they’re all gone.

Black Ninja Parts Tshirt

We have a lot to offer with our web parts, super support being one of the main things you can expect. We’ll be doing our best to answer any questions, field any support issues, and overall, ensure our clients and customers get the best experience possible when purchasing with us.

We’ve also got a lot planned for the future in terms of more web parts and unique applications built right into SharePoint, so please, please, if you have any feedback or questions, reach out to one of us, we hope to surprise you with our quick and friendly response. We love it when we get superior customer support from the products we use, so our aim will be to provide our customers with the same level we’ve come to expect and appreciate from other vendors.

So check our the site, come get a shirt, and have a great week at SP Conf 2011. I hope to meet some of you there and look forward to participating in the live blogging that’s been setup by SharePointTechEdu.

Let’s start with some basics. If you use the following guide for configuring FAST (and I usually do) http://technet.microsoft.com/en-us/library/ff381243.aspx, then you should be aware of:

• You configure two service applications for FAST: FAST Content and FAST Query SSA. FAST Content is a FAST Search Connector. FAST Query SSA is FAST Search Query.
• The FAST Content service application is where you configure your Content Sources and crawl MOST content. Please note that I say MOST and not ALL. Your user profiles or ‘People’ search, are crawled using the FAST Query SSA.
  
  Please reference this article for details: http://sptechland.wordpress.com/2010/10/08/fast-people-and-content-search/. This is a key thing to understand, because until you initiate a crawl for the Local SharePoint sites Content Source in the FAST Query SSA, you won’t see any people results in the People scope.
• If you’re trying to figure out HOW to crawl your user profiles, make sure that the following url is added to your FAST Query SSA – Local SharePoint sites Content Source: sps3://serverurl.

Some other things I’ve noticed:

• My scopes in the FAST Query SSA service application don’t accurately display the number of items in each scope. I haven’t gotten to the bottom of this yet.
• My Content Distributor port as recorded in the Install_Info.txt was not accurate. Read more here: http://blog.qumsieh.ca/2011/08/02/error-unable-to-resolve-contentdistributor/
• There is a neat codeplex tool for querying your FAST farm to test search results. http://fastforsharepoint.codeplex.com/

And finally, if you come across this error:

The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component ’43fa5edd-3e14-4dba-b54c-7aad045dfdf7′ in search application ‘FASTContent’ is in a good state and try again.

Run the following command:

stsadm -o provisionservice -action start -servicename osearch14 -servicetype "Microsoft.Office.Server.Search.Administration.SearchService, Microsoft.Office.Server.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

So what is SharePoint Weekly. Well, as Nick describes it, it’s “a free, once weekly email round up of SharePoint news and articles.” If you’re like me at all, you really struggle with keeping up to date with all that goes on in a given day surrounding SharePoint. It’s so overwhelming at times, that I could easily spend my entire day reading through blogs and new content just to keep up with it all. I could repeat this every single day, that’s how quickly evolving this community is! At Black Ninja, we’re a bit unique, because we run an Apple shop, using VMWare Fusion to drive our Windows/SharePoint VMs and we are heavy into iOS and Ruby on Rails development. We’ve come to really love and absolutely rely on the weekly updates available in the iOS, Ruby on Rails and Javascript communities. I feel in some ways, the SharePoint side has been lacking a bit when it comes to this type of service.

For example, on the Ruby side, we have so many wonderful weekly podcasts and round ups for content. We’ve even sponsored some of them:

• Ruby5 – Great 5 minute round up of all things Ruby for the week.
• Ruby Weekly – Another great example, and very similar to the SharePoint Weekly format.
• Javascript Weekly – Weekly updates on the javascript world.

I’m a huge fan of this idea, and I’m sure Nick would appreciate any feedback or ideas the community might have on making this service even better. I’m open to supporting it in anyway we can as well. I think what would also be interesting to see is if the SharePoint Weekly concept will need to be broken down further into different categories, such as SharePointDevWeekly, or SharePointAdminWeekly, etc.

So take a minute and sign up here: http://www.sharepointweekly.com/

Thanks Nick for taking the time out to set this up and maintain it weekly.

Scenario: We have a 2 server farm: a single application server, and a WFE. There is a separate SQL Server installation where we host our databases. FAST was installed on the application server, which it’s worth mentioning, was already running SharePoint 2010 Server Search successfully.

After going through the steps for installation, what we’ve got configured are two NEW service applications and one old one:

1. FAST Search Connector
2. FAST Query SSA
3. Search Service Application 1 – to be deleted once FAST was configured correctly

FAST Search Connector is where we configure our content sources. In the case of the SharePoint content source that we had configured, a full crawl was generating several warnings and errors, but not a single success message. Something was not right.

Checking into the event logs, I found Event ID 2567.

Failed to connect to VCVANKMSSEARCH1.vci.local:13391 Failed to initialize session with document engine: Unable to resolve Contentdistributor

The issue for us was an error in the port listed for the Contentdistributor. Note: for those of you who did not install FAST personally, and need to know what settings were inputted during installation, you’ll find them in the root of the installation folder where FAST was installed.

\\FASTInstallationFolder\Install_Info.txt

Open the above file up, and locate the following configuration section:

---------------------------------------------------------------
 
FAST Search Content Search Service Application configuration
 
---------------------------------------------------------------
 
Content Distributors (for PowerShell SSA creation):   servername:13391
 
Content Distributors (for GUI SSA creation):          servername:13391
 
Default Content Collection Name:                      sp

Notice the port number. Now navigate to:

\\FASTInstallationFolder\etc\contentdistributor.cfg

When viewing the contentdistributor.cfg file, I was able to see that the port number was different from what was specified during installation. It was in fact set to 13390. So by looking at this setting, we know that the FAST Search Connector is going to be configured incorrectly as well.

Open Central Administration, Manage service applications. Click on the FAST Search Connector and select Properties in the Ribbon. Scroll down to the Content Distributors section and change the port number from 13391 to 13390.

In our case, I deleted and recreated the content source, and now the success messages are pouring in and search results are coming back. As always, I would love to know why the port for the Content Distributors was configured differently from what was specified during installation, but unfortunately I do not have the answer to that. If anyone does, ping me and I’ll update this post.

It’s also worth noting that now that my search results are being returned, I am still seeing Event ID 2567 pop up in the logs, and am currently investigating this. Also on my radar are several Timer errors: Event ID 6398 – Failed to communicate with the WCF service.

This issue has caused me quite a lot of grief and at the time of writing this post, is yet to be resolved.

Thanks to all who attempted to help out by providing links to the CU, I’m going to outline in this post what the issue is and why those links don’t work. Hopefully someone else can make use of this and get past where we are now.

I have a current production farm whose patch level is the MOSS August 2010 CU, or 12.0.0.6545. Let’s say I need to add a new server to this farm. If I download the SharePoint Server software for MOSS from the MS site and install it, I’ll end up with 12.0.0.6421, which is SP2. Makes sense. Downloads from MS should be at the SP level, and you apply the cumulative updates as required.

In our case, we required that we patch to August 2010 CU, so that we could run the configuration wizard on this server and add it to the farm. For those of you who don’t know, if the patch level of the server you are adding to the farm is DIFFERENT from the farm itself, the config wizard will fail with an access is denied error in the upgrade log file. So getting the right patch level is important.

Now let’s review what’s currently published on this site: http://blogs.technet.com/b/stefan_gossner/archive/2010/09/02/august-2010-cumulative-update-for-sharepoint-has-been-released.aspx.

Stefan kindly lists all of the CU information for the August 2010 update. Please note I’m not talking about SharePoint 2010 here, but rather the August 2010 CU for MOSS 2007. Anyways, let’s try the following two links from Stefan’s site:

WSS: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbln=en-us&kbnum=2276474
MOSS: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbln=en-us&kbnum=2276472

You will notice that the WSS link has a hotfix available for download, whereas the MOSS link gives you:

The KB article has no public hotfixes. Please contact support if you need immediate assistance.

This means the CU has been pulled. Several phone calls with MS have occurred and I’ve received confirmation from them that the August 2010 CU for MOSS has been pulled due to an issue that affects Project Server. How frustrating! I get that they’ve pulled it, but what about those customers not using Project Server in need of this CU?

It’s been suggested by others and MS that we upgrade the farm to the Feb 2011 MOSS CU. I understand that this is an option, but it’s really not. This will take us days worth of effort to test, plan and upgrade a QA, Staging, Production and Dev environment.

I have noticed that the individual updates that make up this CU are available for download, but I would feel much better patching this server to the exact same configuration as the others. I’m not confident that what’s available now is not different from what’s been pulled.

That’s it, that’s all I have for now, I will update this post as soon as I hear back from MS. They are attempting to get the CU for us in a back channel sort of way. Anyone who has additional information, I’d be happy to post.

Lesson Learned:

WHEN DOING AN INSTALLATION OF A PRODUCTION SHAREPOINT ENVIRONMENT, KEEP THE INSTALLATION FILES SOMEWHERE DOCUMENTED AND ACCESSIBLE SHOULD THEY BE PULLED IN THE FUTURE.

In Rails, we have a concept called Freeze Gems that’s similar to this idea:

Freezing Rails is recommended if you are using a Rails application for a business site or another production environment where stability is the most important concern. If you don’t freeze your application, there is a small possibility that your application might stop working due to compatibility problems when a new version of Rails is installed on our servers.

Reference: http://support.tigertech.net/freeze-rails