Janice's SharePoint Blog

Open a Linked form in Browser view from a SharePoint Workflow Task List

2009-05-04T20:34:00Z

Kudos to Russell Wright on his great article entitled "Using XSLT to Create a Forms Server Link on a Task Form." The premise is that when a workflow is created around an XML form, there is a To-Do item in the task list that links to a view of the form to which the task is linked. Even if you have the library configured to open that XML in the browser, that link will always return the XML file in the client. By modifying the SharePoint Designer workflow slightly with XSLT, you can view your form in a web browser from the task list.

InfoPathDev is on Twitter!

2009-04-22T00:38:00Z

We have created a Twitter account for our forum so that you can keep up with all the blog posts as they happen! Follow us at http://www.twitter.com/infopathdev.

Administrator – Approved Form Templates

2009-03-02T22:40:00Z

Do you have forms that have managed code in them? Are you interested in publishing mobile-enabled forms to your SharePoint site? The presence of code or the fact that the form will be accessed outside of a network requires the need for special handling. In both of these cases, you will need to publish the form as Administrator-Approved form templates.

This tutorial assumes that you have already completed a form with managed code or enabled your form to be rendered on a mobile device.

1. Save your form to your network or local hard drive.

2. Navigate to the site on which you want to store your form. Create a document library with a default document template set to “None.”

3. Copy the address of your document library for later use.

4. From the form, click File à Publish

5. When asked where you want to publish your form, choose “To a SharePoint Server with or without InfoPath Forms Services” and click Next.

6. Paste the address of your document library that you created and click Next.

7. The next page will let you know that you need to publish your form as an Administrator Approved form template. Click Next.

8. Browse to the location you saved your file to and select it. Click Save and then Next.

9. If you like, choose some columns to be promoted to the SharePoint library and click Next twice.

You will see a message that your form was published successfully and you are to give your SharePoint Administrator the information listed on the screen.

10. If you are a SharePoint Administrator with access to SharePoint Central Administration, navigate to the Central Administration web site.

11. Choose Application Management

12. Under InfoPath Forms Services, choose Manage form templates.

13. On the Manage form templates page, click Upload form template.

14. On the Upload Form Template page, browse to the location where the template has been saved to and select it.

15. Click Save. Your file path should be listed in the text box under File Name:

16. Accept the other defaults and click Upload. You should see a message indicating a successful upload. Click OK.

17. On the template that you just uploaded, click the drop-down box and select Activate to a Site Collection.

18. On the Activate Form Template, choose the correct Site Collection to activate it to and click OK. You may now close Central Administration.

19. Navigate to the document library you created for your form. Select Settings à Document Library Settings.

20. In the Customize page of your library under General Settings, click Advanced Settings.

21. In the Advanced Settings Page, select Yes under Allow management of content types and click OK.

22. Back on the Library Settings Page, you should now see a section called Content Types. Choose the link Add from existing site content types.

23. On the Add Content Types page, change the selection on the Select site content types from drop-down menu to Microsoft Office InfoPath.

24. Select the Content Type of your new Administrator Approved form and click the Add button, then click OK.

25. You should now see your new content type listed in the content types list. Optionally you can delete the other content type(s) in the list. For example in the list below, you may want to delete the Document content type to avoid confusion as to what documents should be stored there. Click on Document.

26. Click Delete this content type.

Now when users click the New button in the document library, your Administrator-Enable form will launch.

SharePoint Host Headers

2009-02-16T23:37:00Z

Are you getting “Internet Explorer cannot Display the Web Page” for your Shared Service Provider administrative page?

Recently, I was performing a relatively simple SharePoint installation on a client’s network – a two-server virtual farm using VMs running Windows Server 2008 and SQL 2008, IIS 7.0 with 4 GB ram. We finally got it working and proceeded to create our site collection. When we went back to configure our shared services in the SSP admin page, we could not access it. It simply gave us an error “Internet Explorer cannot display the web page.” After many very quiet expletives (I was with a client, after all), I proceeded to troubleshoot by checking the host header properties in IIS, the configuration of the SSP, and the alternate access mappings (just to be sure) and all looked fine. There was no explanation as to why it would suddenly quit working. I retraced my steps. We had installed SharePoint, created our required three web applications, configured search, enabled Excel Services, created the associated SSP and called it http://SharedServices/, and created our site collection. (Now, you experienced web and network admins are probably saying “Well, of course…”).

But for those who are not experienced with DNS or other possible network challenges (and many SharePoint admins “fall into” their jobs with little or no training in this area), the answer was not so clear.

The problem was that we gave our SSP a “friendly” name by adding a host header. A host header allows users to type in something that they can easily remember, such as http://MySharedServices instead of http://ssp:35648/ssp/admin. We do this all the time for our main SharePoint site collections so our users can type http://MyGreatPortal.com instead of http://servername:80/default.aspx. The difference is that we know what we are going to call it and our network admins (bless their hearts) add it to DNS so that it could resolve no matter where the page was accessed from on the network. Because this is an administrative page, it didn’t occur to me to do that.

Since this page would most likely only be accessed from the server it lives on, there was really no reason to add it to DNS (although that certainly would work). A workaround for this is to add the global IP for the machine to the hosts file and associate it to the friendly name you will use to connect to the SSP Admin page. To do this, access the host file found in <windir>\system32\drivers\etc\hosts (typically <windir> is C:\WINDOWS).

Open the hosts file with Notepad and towards the bottom, type in the IP address (unless you are using a specific IP for the site, 127.0.0.1 is the global IP for the machine), hit the tab key and enter whatever friendly name you are using in your Host Header.

Save and close the file. Open your SSP page and it should display with no problem.

Of course, the alternative is to create your SSP with NO host header and eliminate this issue altogether.

Finally, if you are working with Qdabra’s DBXL alongside SharePoint, be careful to avoid cross-domain issues when working with InfoPath. Otherwise, some of DBXL’s functionality will present errors.