You’re creating a new Service Application, and in the “use an existing application” pool drop-down menu you see listings for many application pools that don’t actually exist in IIS.
How this happened:
You probably created many Service Application Pools when creating old Service Applications that have since been deleted. After you told SharePoint to remove the Service Application, there was an unused Application Pool in IIS that you subsequently removed manually.
How to clean this up:
Open a PowerShell window that has the Microsoft.SharePoint.Powershell snap-in loaded, and use the Remove-SPServiceApplicationPool “APP POOL NAME” command to tell SharePoint that those old application pools no longer exist. The next time you try to create a new Service Application, those old nonexistent options will be gone.
Happy Sharing and Pointing.
This video demonstrates co-authoring in Word 2010. It would be great if they discussed implications on the versions. As we know without checking out documents, versions grow very quickly.
Co-authoring is a bit more difficult to demo on a virtual image in SharePoint training as one needs to authenticate in both browser and Word to impersonate another user.
One thing you may notice between List and Library forms is that there are different controls available, and that Library forms have a superset of the controls available to List forms. The image below has the extra controls available in a Library form highlighted in blue.
Let’s start from the bottom and work our way up to explain why these are missing.
Everything missing here has to do with some sort of repeating element. Repeating elements don’t make any sense in a List form, as you can’t have some subset of your list columns have extra data in them. That’s just not how a list works. If you have columns that allow multiple selections, then you can certainly populate them individually with multiple-selection people pickers or check boxes.
But let’s say we want to have a list where we pick multiple people and multiple cars and remember who drives which car based on that information. It’s true that we wouldn’t be able to do this, but we couldn’t do it in a single SharePoint list anyhow. There is no cross-column relationship possible there, so even if we made sure to pick the same number of people as cars, we still wouldn’t know which car belonged to whom.
Note that if you create a list form that allows you to manage multiple list items with the same form, repeating containers are used by that form to handle that replication.
The only thing extra in this section is the file attachment control. In a library form you can have multiple attachments. You can do the same thing in a list form with the Attachment field, but only one of them is allowed. You can use it to upload multiple attachments, but you can’t have them in more than one section of the List form. In a library, you could have several different attachment controls in various locations.
The first piece missing from the List forms is the option button. This is not to be confused with a radio button and is instead more like a checkbox. While it is possible to re-cast a drop down list box as an option button after the control has been added to the form, it won’t behave like you would expect. Don’t do this. Feel free to experiment, but it won’t behave in any way that you’ll want.
Next we’ll talk about the absent external data column. In a Form Library this allows you to choose from a Business Connectivity Services entity. In a list form, it’s not available. If you go ahead and add an External Data column to the list and reopen the form, the controls available for the columns populated by it will be merely lines of text with no actual link back to the entity. People could put in whatever text they want. I’m sure many of you can think of workarounds for this involving population of options from web services and so on, and those are legitimate solutions, but there is no direct mechanism to mimic that behavior.
Lastly, the bulleted, numbered, and plain lists are missing. Experiment by trying to convert a list box on the List form into one of them, and you’ll find that the behavior is not what you would expect. The basic premise is that that sort of entity does not really exist in a SharePoint List, and with no available analogue the controls have been removed.
You cannot digitally sign a list form. You can’t do it for a library form either, but you can instead sign sections of it. Putting everything into one section and signing that would be functionally equivalent to signing the entire form.
The general theme, aside from the external data issue, is that you’re missing controls because SharePoint Lists do not store all of the data types available in InfoPath forms. Just as Form Library forms are a subset of what is available in standard InfoPath forms, the List forms are a further subset of that.
Until next time, feel free to contact us for any of your SharePoint 2010 Training needs.
The first question you will need to answer before creating your form is whether it will be stored in a list or library. This question is sometimes hard to answer, so we’ll do it by analyzing some extreme cases. Your situation will likely fall somewhere in the middle, so it will be up to you to decide where your case lies on that spectrum.
For our first scenario let’s pretend that we’re working for the IRS. Someone in charge made a deal with Microsoft and our taxes will now be done by saving them in SharePoint lists. For some reason we want to put tax software companies out of business. Our architects already handled the hardware issues that would come from a hundred million people storing their taxes in SharePoint, so we don’t have to worry about that aspect of it at all. All we need to do is decide if we want to use a form library, or just a standard list form.
You may have guessed that we’ll be using a form library, but why? What reasoning drove us to make that decision?
First off, this is an enormously complicated form. Had we chosen a list form, each piece of information would be stored as column data. We’d need thousands of columns to handle every scenario, and many of those requisite columns wouldn’t be used by the majority of people filling it out. We’d be hiding most columns in every single view, and would need to have customized conditional view forms for individual items.
This alone would steer us toward a form library where we get the views for free and only extract the columns that we care about for list views, but what about alternate means of submission? With a form library, we could e-mail enable the list to allow people to fill out their taxes and e-mail them directly to the library. To do the same thing with a list would require custom code on both the form side as well as the “make a new list item” side.
This hints at another reason this scenario dictates that we use a form library: custom code. When you’re filling out your taxes, there are a lot of little things that your tax software is doing for you. It’s checking rate schedules behind the scenes to determine how much you owe. It’s determining if you’re trying to deduct health care expenses that don’t meet the minimum required amounts for deductibility. While some of these examples could be handled with basic validation in a list form, some of the information could be coming from other data sources that aren’t easily reachable from InfoPath.
We could go on for a while with even more analysis pointing to a form library for this extreme case – we didn’t even mention digital signatures, but let’s leave it at that. To boil it down to something more easily remembered and catchy:
Use a library if you’re collecting a lot of data, want alternate submission methods, or need to have custom code running in the background.
Let’s look at another scenario: We want to let people request vacation time through a web form.
What information are we collecting? The employee name, which could just be a lookup to the user information list.We want to know what days they would like to have off, so a start and end date for their vacation. We want to know their department, but we get that from their User Profile information. Maybe we want to know how much vacation time they have accrued? For our example, this is stored in another system and we’ll be looking that up manually when it comes time for approval, as there are currently no software hooks to grab that information via.
So we need three pieces of information: a name and two dates. After we get this information, we might want to have a Gantt view of it to see whose vacations are overlapping. Maybe this only matters by department (so we don’t leave a skeleton crew at an important time), so we pull that column in from the user lookup and have filtered views for each.
Why are we doing an InfoPath form at all? We want the information to be formatted in a nonstandard way, with the two dates next to each other instead of above and below. We also want to ensure that the dates selected are in the future and that the last day is after the first day.
Since the form is fairly basic and we’re using all (or most) of the columns in our list views, we’re doing a custom list form.
Despite what we’ve just outlined, there may be cases where you need to pick the “wrong” sort of form for other reasons, some of which will be outlined in part 3 of this series where we explore the different controls available in the two types of InfoPath SharePoint forms.
In the mean time, feel free to contact us for any of your SharePoint 2010 Training needs.
At Pilothouse, we do a lot of SharePoint Training, but in the course of a week long class there isn’t as much time to cover some of the topics as in-depth as we would like.
This is the first of a series of posts that will discuss many aspects of custom form creation with InfoPath. Here we’re giving a brief introduction to the what and some of the why behind these customizations, and in the next parts we will be digging a bit deeper to learn more about what you can and cannot do with this tool.
As with most things in SharePoint, some seemingly difficult things will become trivial, and some seemingly trivial things will become difficult or impractical. I don’t say impossible because when you know as much as some of us do about the product you can come up with custom-coded solutions to many of those impossible cases, but impractical is a fair term to throw around.
New in SharePoint 2010 is the ability to customize list forms with InfoPath Form Designer 2010. In SharePoint 2007 it was only possible to collect data from these forms with a form library (if you know how to get InfoPath form data into normal lists in SharePoint 2007 without custom code feel free to post your tricks – there are a few ways).
One of many issues with a form library is that it is not an actual list, but a document library. One implication is that you cannot set the item level permissions for the entire list to “view only your own items.” For surveys or other data collection tasks that would prefer individual data to not be shared with others, this was problematic. Yes, you could write a custom event receiver to change permissions on new items that have been added, but at the point where you want to start allowing modifications you have to think a little harder about what the receivers are doing and theoretically have more than one working in concert.
The first parts of this series will be addressing the following questions:
- When to use a list form vs a form library
- Differences in available controls between the two types of InfoPath forms
- Having different custom Edit, New, and View forms for the same list
I decided to take a look at Office 365 to let Microsoft host SharePoint for us, but it turns that Office 365 wants to do a lot more thanjust SharePoint hosting for you.
Here is our current collaboration/document management setup
- We host our own SharePoint server on a dedicated server which is probably an overkill as far as the hardware goes, but it nice to have.
- We let Google apps handle our email. Google docs are ok, but I prefer SharePoint for document and list management.
- Our main public website uses a simple solution of DreamWeaver + SVN
The initial setup process for Office 365 is very simple. My initial impression of the admin page was really good.
I did not move email hosting to Office 365 as it was not my intention and Google seems to be working just fine, plus Android in it integration is great.
I was a bit disappointed with the way SharePoint was set up. It seem like you get one site collection and you are forced to have a top level site with a custom publishing master page. Collaboration and document management are supposed to take place at the sub sites.
- http://pilothouse.sharepoint.com – main site collection setup with a custom publishing master page. The intention here is that you would move your public website here.
http://pilothouse.sharepoint.com/teamsite – sub site with a team site template
I believe that Office 365 would be better off just focusing on internal collaboration and document management instead of trying to build a so so external site on SharePoint. After looking around this setup I decided that I like the flexibility that we currently have with our SharePoint setup and will not be moving anything to Office 365 just yet. Also, I don’t have a Windows 7 phone to see how well the integration works; I assume for some organizations it will be important.
Overall, I never felt that the publishing feature was how you start selling SharePoint ot a business that has not used SharePoint before, but ti certainly seems a strategy for Office 365. We’ll see if they change it soon.
This only applies to Site Collection backups, and not farm backups. Farm backups are apparently just fine as long as you run the psconfig update command afterward. I haven’t had to deal with these specifically yet, and if those have the same issue then I’ll post at a later date (when I come across those issues).
If you have a site collection backup from before a service pack was applied, you can not restore from that backup after the service pack. What you’ll want to do is to set aside another environment (even if it’s a virtual image) from before the update in case you need to restore one of these old backups in the future. After you have the content database restored with the site collection in it, you can attach to the new environment and run psconfig’s update to get it up to speed.
The pre-SP1 environment I stood up for this purpose was a Windows 7 developer install of just Foundation on no domain at all. The final destination was in a domain running server.
Yes, I just had to do this. Yes, it was a huge hassle. Yes, it worked.
All of Pilothouse summer classes are for SharePoint 2010. Our last SharePoint 2007 class was held last week in Las Vegas. It is unbelievalbe that we run 2007 classes for almost five years (starting in June of 2006). SharePoint 2007 is definitely a great product, but as not as good as 2010.
So while teaching a class the other week, I was asked how to implement a “widget.” This widget may be a web part and available on certain pages within sites, but may also be something that needs to be placed in a master page to show up everywhere. The point is that the developers don’t know up front how the widget will be used. Also, remember that Web Parts should not be included in the Master Page. Yeah, you can get them in there; but you have to be careful to put them after the Web Part Manager. Designer won’t even let you try to place them without manually typing the tags in.
I was in the last day of the course, where I offer to “just do” something that they will need to implement so they can see the thought process that went into it. In retrospect I should have come up with the idea immediately, but from start to working proof of concept (including the actual functionality) for their example was only 20 minutes.
After some “thinking out loud,” I came to the conclusion that a Visual Web Part would solve their problem in one fell swoop.
A Visual Web Part is one that is merely a wrapper for a control, and the expected development case is to do all of your coding inside the control itself. The Web Part piece of it merely loads it in the overridden CreateChildControls method and displays it to the user. So what you’re left with is a control in the SharePointRoot/Template/ControlTemplates folder on disk, and a web part in the gallery.
The key insight here, which very well may be pointed out in literature that I haven’t read, is that you could also directly place the control onto any safe or master page in SharePoint. Putting it into the Master Page will also effect Application Pages in SharePoint 2010. You end up with a Control and a Web Part for free.
Note that using a Visual Web Part takes away your ability to Sandbox the solution package, and if that is an issue you’ll need to come up with an alternate solution. Was that a pun? I’m not sure.
In Summary: A Visual Web Part also gives you a control, which could be added directly to master pages (or anywhere else) if your deployment needs change.
The image above lays out a potential situation that can be created in any SharePoint deployment. What happened was that a site column was created in a site, and that site was later saved as a template. At that point, it was available for use throughout the site collection in question, and some sites were created based on the template.
What happens is that the site column ends up in the gallery for each site using it – sites A and B (in magenta) in the graphic above.
The normal behavior for site columns is that they are available at the site in whose gallery they reside, as well as any subsites. From a subsite the column is not editable, and when you go back to the site where it exists changes can be pushed down to any list using that column. But what really happens?
Create the situation above, and use a choice column for the site column that is part of the template. Give it some choices, save the template, and then go make some sites based on the template. Make sure that they are not part of the same subtree (as in the image), just to really drive the point home.
Make some lists in both sites based on your choice site column.
Now, update the column in the gallery for site A by adding a new choice, and have it propagate changes to all subsites. Look at the lists using that column in site A. The list column based on that site column will have been updated, which is the expected behavior.
What comes next could be unexpected. Look at the list columns in Site B. Those based on the choice site column that you created will also have the new option available.
Next could be even more unexpected. Check the site column gallery for site B, which also has the same site column defined. That version of the site column will be unchanged.
You could continue the experiment by modifying the gallery version of the column in site B, telling it to propagate changes below, and watching the change also effect site A’s versions of the columns in its lists.
So what is going on here?
When a site column is defined, SharePoint creates a GUID to associate with it. You can see what I’m talking about by checking any feature in the SharePointRoot/Features folder on disk, and noting that there is a globally unique ID associated with it. When you modify a site column in a gallery and tell it to push down changes, it looks at every LIST column in that site collection, and based on that ID swaps out the definition. It does not, however – as our experiment showed, update anything defined in any gallery.
Now, this behavior is completely fine almost all of the time. If you have two disparate sites with different galleries and manage to give two distinct site columns the same name, they will still have different IDs. If there is a parent-child relationship, it will be disallowed and you’ll be forced to update only the parent version, as the child gallery will show the column as read-only. We defeated the use case by putting our column into a site template and using that instead, which preserves the ID.
Will this behavior happen across site collections? Not at all, even in the same content database. Try it to find out.
You may wonder if this behavior applies to site content types as well. Try it, and post your results.
The morals of the story are to be careful when putting site columns into site templates, and that you can learn a lot about how SharePoint operates by tinkering with your ideas and questions. Since behavior is subject to change across versions of the product (even minor patches), it is always best to try things out before assuming certain behavior.
In Summary: Define a site column in a site template, make sites based on that template in various locations in your site collection, use the site column in lists. Now updating any gallery version of the site column will update every list using it, regardless of the tree position of the list.