Dave Wollerman's SharePoint Blog

Being able to write commands that extend the functionality of STSADM is awesome. It is way better than having to write it from scratch to make it represent the same feel of STSADM. I ran into speedbump when i tried debugging my operation line by line. I found that I had to add in the following to the "Debug" tab on the project properties screen.

Start Action -> Start External Program = c:program filescommon filesmicrosoft sharedweb server extensions12instsadm.exe

Start Options -> Command Line Arguments = -o <operation> -url <url> [plus additional properties that need to be included in your custom command]

Below I am starting a list of antivirus products available for SharePoint 2007. I have alot of people ask me about AV for sharepoint, but there is no real understand on who develops products for it. There are a few more vendors for SharePoint 2003 (McAffee, Avast, AVG, BitDefender, and Symantec). The list is not in order of any type of importance. 

Microsoft Forefront Security for SharePoint: (trial available)
http://www.microsoft.com/forefront/serversecurity/sharepoint/default.mspx (also includes license for Antigen antivirus for SharePoint 2003)

Microsoft also has a virtual lab available showing the use of Forefront Security (Antivirus)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032329673&EventCategory=3&culture=en-US&CountryCode=US

Trend Micro Portal Protect for SharePoint: (trial available)
http://us.trendmicro.com/us/products/enterprise/portalprotect/index.html

There is a problem with the workflow in MOSS. For some reason Microsoft decided that they need to purge the workflow associations after they are 60 days old. This means that when you looks at the workflow history for an item you will not see workflow history older than 60 days. The information about the workflow is still in the tasks and workflow history lists, but the association between the workflow and the item has been purged from the database. I know of some people who have already contacted Microsoft about this problem and created support cases for it. The answer they keep getting is that it is by design for performance reasons. What about auditing reasons Microsoft, don't you think this will be a huge issue for enterprise clients?

My question is how many clients out there are using this for important business processes thinking their audits will be covered? If you are a Microsoft support customer and are using workflow for important business process that will be audited. PLEASE CALL THEM AND COMPLAIN!!! The only way it seems that Microsoft will move on this is if they get a large enough response from the community. Obviously a couple large enterprise companies (50,000+ employees) aren't enough to concern them.

Below are some details of the issue and some correspondence with Microsoft support…

• Document losing their “approval workflow details” after 60 days.
   
• Workflow details still on site, but no longer associated to respective documents.
   
• Issue identified by Microsoft and not listed as a bug as originally told – this expiration of 60 days is something that was done purposely – “by-design”.
   
• MS provided code that will allow us to extend the document/workflow history relationship past 60 days. (code needs to run everyday to change new associations)
   
• Testing has not been done by Microsoft for the provided solution.

Here is a list of findings and concerns on this situation:

• FINDING – A table that contains associations between workflow details and documents contain this expiration date of 60 days.
   
• FINDING – This field can be changed, on a site basis, to a maximum of 9999 days – 27 years or so. at least according to Microsoft (untested as of yet).
   
• PROBLEM – If code works successfully, it will have to be ran constantly. This must be done as new workflows are completed on documents or risk losing the associations after 60 days.
   
• PROBLEM – This impacts all sites in a content database as they will all use this association table. I foresee a problem with maintaining separate expiration times for different sites.  This will now become the responsibility of the operations group to maintain, based the respective customer. If it doesn't retain this permanently or semi-permanently, then this should be a setting that is configurable at a site or library level, providing the customer the ability to set the expiration period.
   
• CONCERN – From audit perspective, Sarbanes or other, this is totally unacceptable. NO WARNING to indicate that critical detailed information will be disassociated with its counterpart document after 60 days. Unwary users could be audited 12 months after a document went thru a workflow approval and be none the wiser that their document actually was approved and their workflow history was “cleaned” 10 months earlier.
   
• CONCERN – One of the biggest selling points for MOSS was the ability to have enhanced workflow on your documents. Almost any company is going to be negatively impacted by this “feature”. Not only financial or healthcare companies, but any financial department within a company is going to be impacted if they use this feature in MOSS. I can't question the DOD5015 compliance as I do not know if proof of approval history is a requirement. If it is, it certainly is not DOD5015 compliant. 

There are a number of companies out there that utilize SQL transaction log backups for their SharePoint solution. This of course is fine and supported by Microsoft, but if there is a complete disaster then the SharePoint administrator will have to piece everything back together. My recommendation is to run the SharePoint full backup option in conjunction with the SQL Transaction log backups.

SharePoint backup / restore (either through the central administration web site or using STSADM utility) will put the farm back together in case of a diaster. SharePoint restore from a SharePoint backup will require the administrator to run through the configuration wizard to build out a new central administration. Once central administration is available, SharePoint restore can run to put all the pieces back together. The SharePoint restore will build out all the IIS virtual server, application pools, web applications, shared service provider, content indexes, and all the links in between.

Once everything is pieced back together SQL backups and be restored over the existing databases that were restored from the SharePoint restore process. Plus the transactions logs can be replayed up to the point of the last transaction log backup.

Now I know your going to say that it sucks because you have to backup in 2 places. Yes this is true, but you only really have to run the SharePoint backup when there is a change to the farm. Changes would included adding a new web application, shared service provider, etc. Also keep in mind that if you will want to backup any changes to the IIS virtual server in case there was host headers and SSL on the site. Plus you will want to make sure you have a backup of any custom solutions and such.

This will become my list where I log some of the issues between running a form with an InfoPath rich client versus inside of SharePoint Form Services, outside of the warnings given within the designer. Please be welcome to share yours as well. I am sure there are a ton out there that Microsoft has not documented and it will be helpful to everyone to have a repository for this information.

1. Rules on Controls
Rules on a control run differently in the rich client compared to form services. In the rich client the rules run as "on-click" events where as in form services they run as "on-load" events. This is strange since rules are allowed in form services, you think that they would act in the same manner. The workaround for this issue is for the rule set not to run on load there has to be a condition defined on the rule, even it is a bogus condition that will always return true.

2. Closing a Form
Closing a form should be a simple matter to understand, except in the rich client the form actually closes and goes away. In form services when the form is closed a message is shown stating the form has been closed. What form services does allow you to do what I have found is provide a "Source" querystring attribute in the URL when opening the form in the browser. The value for this attribute is used when the form is closed to redirect the browser. So, the workaround I did for this issue was to create a basic HTML page that informs the user that the information has been saved and provide a link back to the form. On the forms I want to actually close the browser windows, I include a javascript statement that just does a windows.close() call and provide a link to these HTML pages in the Source attribute where needed.

3. Form Template Parts
With InfoPath 2007 you have the ability to create custom form template parts. These allow a designer to create a "control" for use in multiple InfoPath forms. Form template parts are convienent and work in all flavors of compatability in InfoPath 2007. What it is lacking is the ability to have custom managed form code in a template part. It allows rules, but no programming of managed code. So even though the framework can be shared in the template, the code has to be written in the InfoPath form itself.

4. Document Information Panels
With InfoPath 2007 you have the ability to create custom document information panels for use in Word, Excel, and Powerpoint when working with SharePoint fields. Of course with InfoPath comes restrictions on what you can and can't do when developing document information panels. The following list outlines some of the issues that came up when developing in a document information panel

• Cannot add or edit the main datasource
• Any control added to the form has to bind to an item in a datasource
• Multi item select region does not work. This is mainly because the control has to be tied to a repeating item in the main datasource. This is because the control will add/remove nodes in the repeating group as items are checked. The control cannot add/remove nodes to a secondary datasource. Since you cannot modify the main datasource, you cannot use this control in a document information panel.

This post is probably not relevant to most people, but I keep running into the same discussions with companies that are setting up SharePoint for the first time or have already set it up and are asking a lot of questions about why their environment is not as flexible as they thought it was going to be. I also seem to get into discussions about this with other SharePoint integrators who don't feel that this topic is important. Maybe they assume people already know the concept or maybe they don't understand it themselves.

I feel that understanding the architecture around the definition and maybe the purpose of sites and site collections is the building blocks of SharePoint. Most people coming into SharePoint for the first time see it as if it were a single web application with a ton of features and settings. They also look at it as if the taxonomy of the sites were a physical heirarchy on a file system. Its hard for some people to grasp the understanding that everything is stored in a database and there is no real physical site hierarchy.

With the use of managed paths, site collections can impersonate a physical hierarchy for a means of organization, but the site collections are still on the same level as far as SharePoint is concerned. A Farm, Web Application, and a Site Collection are all "Containers" (or in active directory thinking "organizational units").

As far as when to use a site collection as opposed to using a sub-site, that is based on the organization itself. Usually it is the IT department's goal to implement the SharePoint system. In most circumstances these people are infrastructure experienced and not experienced in deploying applications. This results in a hodge-podge installation of SharePoint with a single site collection to house everything known within the organization. This will result in a failed installation, since there is no room for scaling. Plus IT will either be burdened with the task of maintaining all the structure and security, or they will demand it (sometimes IT doesn't get the idea of distributed security).

Site collections will allow the IT department freedom to maintain just application itself without the worry of security or content hierarchy maintenance. The following is a list of what an individual site collection offers.

For the Users:

• Dedicated Recycle bins
• Dedicated usage Reports
• Distributed administration (site collection administrators)
• Dedicated search scopes, keywords, and best-bets
• Custom feature deployments
• Dedicated language translation maintenance
• Dedicated galleries for web parts, master pages, content types, site columns, site templates, and list templates
• Dedicated shared libraries, such as site collection images and site collection styles
• Dedicated real estate (Self Containment)

For the IT Administrators:

• Site quota templates
• Distributed administration
• Site locking
• Database maintenance options
• Backup / Restore abilities
• Content Deployments
• InfoPath forms services global template targeting

I have 2 big, at least what I think is big, points on why to use site collections. The first one is site quotas and recycle bins. The issue is the recycle bin is based on site collections and the quota for a site collection. If everyone shares a site collection, then they share the recycle bins storage size. The example I usually give is HR deletes 1MB per day and IT deletes 1GB per day. With a 5GB site quota, HR content will be flushed through the system a lot quicker if they share a recycle bin. This results in having to restore a database to get back a single document. (You know it will happen, Murphy's Law). If they were in separate site collections, then the HR recycle bin would be valid for months maybe years with a 5GB quota because it is only affected by their deletions.

The second point is distributed administration. For most small companies this might be a moot point, but for high content driven organizations with a small IT force. It is a godsend for IT. IT doesn't know who should be able to see what content, besides how it should be organized. This is the job of the content owners and users. SharePoint site collections offers IT the ability to create a site collection for a project, team, department, document, or whatever the needs are, then assign an owner and hand it off to them. Now IT has time to work on IT related issues and the content owner now has their real estate to start developing. By this I mean, they now have the ability to quickly create libraries, calendars, meetings, wikis, whatever they feel they need to efficiently organize their content in a meaningful manner to the people who will be using it…. THEM. Plus the ability to allow users to either read or contribute to the site. This is huge since the content owners best know who needs to author, read, consume the content, plus how it needs to be organized. IT usually has no clue which then leads IT down a long time consuming road to interpret how the content owner needs it and will probably have to keep changing it constantly since they are the owner. IT has their own work to do as well.

I went through and ran through setting up SSO for a test environment to see what all the hype was about. I can't believe that the administration accounts are that confusing to setup. Here are the steps that I took to get the SSO configured and the database created.

1. Create a domain service account (ex: Demosa-ssoadmin)
• DO NOT ADD ACCOUNT TO ANY DOMAIN GROUPS YET
2. OPTIONAL: Create a domain security group with "Group Scope" as "Global" and with "Group Type" as "Security". Do not select "Distribution" or "Local Domain" options. (ex: SSO Administrators)
• Add in the demosa-ssoadmin service account
• OPTIONAL: add in other domain accounts for users who will be administrating the SSO Application Definition files. 
3. Add the domain security group (SSO Administrators) to the local administrators group on all SharePoint WFE servers.
4. Log into the WFE server that is running "Central Administration" web site. 
5. Start the "Microsoft Single Sign-on Service" in the Windows Services MMC.
• Set to "Automatic"
• Run the service under a domain service account (ex: Demosa-ssoadmin)
• Start the service
6. If there are more WFE servers plus servers running Excel Services, Start the Microsoft SSO service on those servers now. If Buisness Data Catalog search is used then also start the SSO Service on the index server as well
• NOTE: the first server that the service is started on becomes the encryption key server
7. In SQL, make sure that the domain service account (Demosa-ssoadmin) running the Microsoft SSO service has the following roles assigned on SQL Server
• dbcreator
• securityadmin 
8. Remote into the "Encryption Key Server" (Should be the first server that SSO was started) and fire up SharePoint Central Administration
• Make sure you are logged into Central Administration with a SharePoint Administration account
9. Navigate to "Central Administration -> Site Settings -> Permissions" and add one of the following with "Read" permissions
• IF USING GROUP: domain security group (SSO Administrators)
• IF USING USER: domain service account used to run the service.
10. Also add the domain service account used to run the service to the Farm's administrators group
11. Navigate to "Central Administration -> Operations -> Service Accounts" and double check the "Single Sign-on Service" credentials. If not set to the domain account (demosa-ssoadmin) then set it up here as well.
12. Navigate to "Central Administration -> Operations -> Manage Single Sign-On -> Manage Server Settings" to setup SSO for SharePoint
• Single Sign-On Administrator Account: GROUP: DemoSSO Administrators or USER: Demosa-ssoadmin
• Enterprise Application Definition Administrator Account: GROUP: DemoSSOAdministrators or USER: Demosa-ssoadmin
• Database Server Name (use netbiosinstance naming convention)
• Database Name
• Timeout settings (I used Default)
• Ok

Once this runs though there should be a database created and one should be able to start configuring the encryption keys and other settings related to SSO for SharePoint. I found a few sites that spell this out, but there was alot of fluff around it, hopefully I dumbed it down enough to get things rolling. I will be posting more information as regard to the configuration of SSO now that the setup has succeeded in the future.

I am not sure about everyone else, but I have seen SharePoint databases grow out of control. This happens especially when you have people install SharePoint that don't maintain or even understand SQL Server 2005. I have seen configuration databases around 12GB where 11GB+ of that is all log file.

A lot of this is because the configuration and content databases are set to a Full Recovery model by default and full backups do not automatically truncate log files. I have seen where you can set the databases to a "Simple" recovery model, but this limits the customer in case they want to do transaction log backups or log shipping.

I haven't came up with a fool proof plan as of yet, but what I have found out is that one can free up space if need be manually. After a full backup you can shrink and truncate the log file to any size you need with the following command.

dbcc shrinkfile (<LOGICAL LOG FILE NAME>,<SIZE IN MB>,truncateonly)

Also, be sure to change the growth rates on the log file. By Default they are set to 10%,Limited to 2TB. The 10% adds up quickly on transaction heavy databases such as the configuration database. I would specify a set size instead of a percentage.

I came across a weird thing the other day and wanted to share it. I was working with a my site and uploaded a large image for my user profile image. When it updated my profile, it did what I expected it to do. It put the image into a picture library and the library created a small and medium thumbnail of that image. The weird thing was that any reference to that image as part of my user profile (my site, people search, or public profile page) the system displays the large image I uploaded, just scaled.

Ok, so this isn't that big of a deal. But as a lot of people are aware, users don't usually understand to scale their images down before using them in applications. So the problem with this is you can potentially have a people search where there are numerous results, but the images being downloaded to the results screen are the full sized user profile image being scaled to a thumbnail size. My thought is why can't it just reference the thumbnail it created in the picture library automatically. I am sure the page will load and the images will just be slow to render on the screen, but this could be misread to think that SharePoint is responding slowly.