1.  Use custom code / tool to programmatically create a SpChoiceField without choices, and switch the EditType to RadioButtons:

list.Fields.Add(”This is a label, no input options will be displayed!”, SPFieldType.Choice, False)

Dim choicefield As SPFieldChoice = list.Fields(”This is a label, no input options will be displayed!”)

choicefield.EditFormat = SPChoiceFormatType.RadioButtons
choicefield.Update()

I have tested this, it works.

2. Edit your ~\12\TEMPLATE\LAYOUTS\qstnew.aspx. Remove the javascript validation at line 1077 that checks for no choices. I have not tested this.

3. Maybe even create a new qstnew.aspx that does not validate the form input for no choices, and use that your self only.

Looking at all that….it’s almost easier to create a custom field…

Oh well.

It seems that the optional last parameter is not really optional, you have to include it. If you include it as a blank “” string or a null/nothing value, it still throws execptions….

1. If you are catching Exceptions on SOAP calls, stop. Start catching System.Web.Services.Protocols.SoapException .  There’s a member called “Details” which will give you the actual error, and not the generic soap exceptions.

2. The documentation says that the WebID field, if not given, will use the URL property of the Lists web service reference object. Well that should work right ? Well no… i guess they changed the way this property works. It appears to not be set. It appears that in an app.config file there is a config parameter that corresponds to this URL parameter. Im guessing that when the empty URL parameter is found, it goes to the app.config to find it, but it’s already passed the test for WebID, and so now it’s required.

This seems to be a change from the way  WSS 2.0 worked. An uneeded change. A stupid change.

Grr.

For each event that you want to limit to last week’s data, let’s go with “modified” for now, create two new fields:

ModifiedReportStart

Make it a calculated field, and give it the formula:
=Modified+7-WEEKDAY(Modified)

This will put this date at the start of the Next Week after “Modified”

ModifiedReportEnd

Make it a calculated field, and give it the formula:
=Modified+14-WEEKDAY(Modified)

This will put this date at the end of the Next Week after “Modified”

Create a View with a Filter

Filter where:
ModifiedReportStart is less than [Today]
AND
ModifiedReportend is greater than or equal to [Today]

Tada.

If you looking into trying to make these date filters dynamic, good luck, I haven’t figured or found that one out yet. BUT, here’s where you find the reference for filters and formulas in sharepoint lists on your sharepoint server:

C:\Program Files\Microsoft Office\Office12\1033\STSLIST.CHM

I see a whole lots of posts concerning the search drop down box missing some of the defined scopes from SharedServices. I recently ran into the problem on our farm and I thought I would pass along the fix.

The best place to start is to ensure that you actually have a SearchCenter site installed on the site. Without this, there will be no place for the scoped searches to land, and the scopes will not show up.

Once you have ensured that SearchCenter is installed, then go to SharedServices and make sure that the scopes are there. With MOSS, you will usually get two defined scopes out of the box, All Sites and People. Make sure that the scopes are there and that there is data in them.

If 1 and 2 are ok then next go to the base site for your collection. Log in as the SysAdmin and click on “Site Settings - Modify All Site Settings”.

From All Settings, find the Search Scopes link in the Site Collection Administration column and click on it.

Sometimes SharePoint loses the scoping information, if it has lost it for your site collection, you will see your two scopes here in the category of Unused Scopes. In order to reset your scopes correctly, click on the “New Display Group” button on the menubar.

In order for the Scopes to show up in the Search Drop Down, place “Search Dropdown” in the Title box here. Place a description in the next field. Now check both of the scope “Display” checkboxes and select a position for each (usually it is All Sites (1) and People(2). Make the default scope “All Sites” and click on “OK”

When you return to the view you will see your defined scopes in the new Category: “Display Group: Search Dropdown(2)”. And when you go to your site you will see that the scopes are now part of the dropdown box.

To set up Advanced Search, create another Display Group. In this group place “Advanced Search” in the title and check on “All Sites” and make “All Sites” the default, BOOM! Advanced search shows up.

Hopes this helps some of you frustrated Sharepoint people

JMC

Fixing those pesky DCOM event log error 10016 in a SharePoint farm environment

Posted by Søren Nielsen under Deployment , SharePoint 2007 , Troubleshooting

I’m responsible for a couple of SharePoint 2007 (MOSS) farms where all SharePoint servers showed the following error in the system event log:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10016
Date: 1/17/2007
Time: 4:31:48 AM
User: <DOMAIN>\sa_adm
Computer: <SERVER>
Description:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{61738644-F196-11D0-9953-00C04FD919C1}

to the user <DOMAIN>\sa_adm SID (S-1-5-21-162740987-2502514208-3469184634-1119). This security permission can be modified using the Component Services administrative tool.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The error would show up at regular intervals in clusters (4-12 at roughly the same time) and there would be a few more with other usernames and other class id’s. I had two fully functional farms with 3 SharePoint servers each and a number of standalone development machines. They all exhibited similar behavior.

The error listed above is that the user running the Central Administration web application doesn’t have access to activate (instantiate) the IIS WAMREG admin Service object (search the registry for the CLSID).

Strangely enough I didn’t observe any functional errors in the farms as a result of these errors – nothing seemed amiss (plenty of stuff didn’t work but none directly related to this).

An important note here is that the service users used in the farm are all standard domain accounts and only given additional local rights by the SharePoint installer and Central Administration (The one exception is that “aspnet_regiis -ga IIS_WPG” was executed after SharePoint install and initial configuration).

The following procedure removes the errors from the event log without compromising the entire security setup (yes, assign administrative rights for the service users would do the trick too) and has been verified by Microsoft consulting services.

On each SharePoint server do the following:

1. Click Start, Click Run, type “dcomcnfg” and click ok
2. Expand Component Services / Computers / My Computer / DCOM Config
3. Right click IIS WAMREG admin Service and choose Properties
4. Click the Security tag
5. Click Edit under Launch and Activation Permissions
6. Click Add
7. In the Select Users, Computers or Groups type computername\WSS_WPG and
   computername\WSS_ADMIN_WPG
8. Click ok
9. In the Permissions for UserName list, click to select the Allow check box
10. Click Ok twice.
11. Go back to the main Component Services window, right click the “netman” node and select Properties
12. Click the security tab
13. Click Edit under Activation Permissions
14. Click Add on the Launch Permissons Dialog
15. Enter “NETWORK SERVICE” in the edit box
16. Click Ok
17. Enable all the checkboxes for the NETWORK SERVICE
18. Click Ok twice
19. Finally, run “IISReset”

That should be it!

A little less event log errors to worry about – there are plenty left on a reasonable complex SharePoint farm…

As a side note: The above error also shows up in other applications as well – I’ve heard about it for exchange servers as well and more applications are probably affected. In that case you’ll need to search the registry for the actual DCOM application and assign the rights to another local group (or username as a last resort).

Looking into the Export log, we found:

Error: Access is denied. (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED))
at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex)
at Microsoft.SharePoint.Library.SPRequest.GetFileAsByteArray(String bstrUrl, String bstrWebRelativeUrl, Boolean bHonorLevel, Byte iLevel, Boolean bUnprotected)
at Microsoft.SharePoint.Deployment.FileSerializer.SaveFile(SerializationInfo info, ExportObjectManager objectManager, ExportDataFileManager fileManager, SPExportSettings settings, SPWeb parentWeb, Boolean isGhosted, String setupPath, String setupPathUser, Byte setupPathVersion, String webRelativeFileUrl, Int32 size, Byte level)

The import error was:

Error: The file  cannot be imported because its parent web /sites/grizzly/SAISB/grizzly does not exist.

Progress: Importing File Lists/General Discussion/Threaded.aspx.

  [8/27/2007 3:20:18 PM]: Error: Current item failed in the export with the error message: Access is denied. (Exception from HRESULT: 0×80070005

The fix was to grant the person doing the export site collection administrator status, then do the export.

The document could not be opened for editing. A Windows SharePoint Services compatible application could not be found to edit the document.

dialog box error message when trying to open a word document in document library using the “Edit in Microsoft Word” drop down command.

After some investigation it turned out that they had created a HUGE URL trail in side the document library by creating folders with really long special character laden names. The URL was around 300 characters long or some such nonsense. IE’s limit is around 2084 so its not IE, probably SharePoint or Word related limitation on URL length, or some special character interference.

I shortened all the directory names and took out some of the special characters and it seemed to clear up the problem.

http://support.microsoft.com/kb/926370

We restarted the Windows SharePoint Services Timer ( SPTimerV3 ) in Services Console, and this resolved the problem.