Clint

I while back (about 18 months ago I think) my team ran into an issue while working on a system for the Department of Defense. The issue occurs when the "System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing" security setting is enabled through Group Policy or Local Security Policy on a WSS or MOSS server. After much research and gnashing of teeth, we finally traced the issue back to the fact that the .NET Framework uses AES encryption as the default. Unfortunately, at least in Windows Server 2003, the Microsoft implementation of AES had not been FIPS validated and the application immediately threw an error when it tried to use the algorithm. We were able to resolve this issue by specifying a "validation" attribute as well as a "decryption" attribute in the SharePoint web.config files for all Content web applications as well as SharePoint Central Administration. We used 3DES as the value of the attribute. Any of Windows Validated FIPS Compliant algorithms should work in this setting. SharePoint specifies an encryptionKey and decryptionKey under the machineKey element but other than that, once the attributes are added, you should have a machineKey element that looks something like

<machineKey validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7 AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B" decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F" validation="3DES" decryption="3DES"/>

 This same fix would apply to any ASP.NET application that is using View State Encryption and displays the "This Implementation is Not part of the Windows Validated FIPS Compliant Algorithms" error message when trying to view a page.

So… why am I just now writing about this? Yesterday, a friend of mine sends me an email that says "Remember when we hit that encryption issue with SharePoint… How did we solve that?" Luckily, I still had a demo server that had the modified machineKey element and I remembered enough to know where to look. I also know that there are some other articles out there about this issue now, but I can never find them when I need them.

Here are a couple of related references: http://support.microsoft.com/kb/911722, http://www.dscoduc.com/post/2008/05/03/FIPS-Compliant-Algorithms-and-IIS.aspx, http://stevesps.blogspot.com/2008_10_01_archive.html, http://msdn.microsoft.com/en-us/library/ms998288.aspx.

I have been doing a lot of work with custom content types and content type event receivers lately.  I have run in to a few bugs that I think are worth noting.  Before I get in to the details, I would like to say that some of the issues that I experienced were, quite simply, because of a lack of attention to detail on my part.  That being said, I'm quite sure that I'm not the only person that has ever experienced these issues.

 First of all, here are the steps to recreate the problem:

• 1. Create a new set of site columns using the Microsoft Feature 12TEMPLATEFEATURESfields as a template. (see fig. A)
• 2. Create a new content type that uses these fields (see fig. B)
• 3. Apply these fields to a custom list definition see fig. C)
• 4. Add the list to a site, when you try to add a new item there should be fields missing from the newform.aspx page.

Fig. A)

            <Field ID="{76d8a613-d5b1-4c80-a5c4-b0ad2c159743}"

               Type="Text"

               DisplayName="Field1"

               Description="Test Field 1"

               Required="FALSE"

               Group="Custom Columns"

               StaticName="Field1"

               Name="Field1">

      </Field>

      <Field ID="{F4C72115-5BAF-47ce-BD10-1344277DCB01}"

               Type="Text"

               DisplayName="Field2"

               Description="Test Field 2"

               Required="TRUE"

               Group="Custom Columns"

               StaticName="Field2"

               Name="Field2">

</Field>

Fig. B)

<ContentType ID="0×0100ff35ff607de941ff85edc7e2e52d5ba4"

      Name="TestType"

      Group="Test"

      Description="Test Type 1"

      Version="0">

    <FieldRefs>

      <FieldRef ID="{76d8a613-d5b1-4c80-a5c4-b0ad2c159743}" Name="Field" />

      <FieldRef ID="{F4C72115-5BAF-47ce-BD10-1344277DCB01}" Name="Field2" />

    </FieldRefs>

 </ContentType>

Fig. C)

Fields:

            <Field ID="{F4C72115-5BAF-47ce-BD10-1344277DCB01}" Type="Text" DisplayName="Some Text" Description="" Required="FALSE" Group="Custom Columns" StaticName="Field2" Name="Field2" Customization="" SourceID="{5405662c-cce9-45d2-a057-9389a9b8e8f1}" ColName="nvarchar12" RowOrdinal="0" />

      <Field ID="{76d8a613-d5b1-4c80-a5c4-b0ad2c159743}" Type="Text" DisplayName="Some Text" Description="" Required="FALSE" Group="Custom Columns" StaticName="Field1" Name="Field1" Customization="" SourceID="{5405662c-cce9-45d2-a057-9389a9b8e8f1}" ColName="nvarchar13" RowOrdinal="0" />

So why are these fields not showing up on your forms?  Well, it may seem a little bit nitpicky on the part of SharePoint, but for some reason all of the fields have to match exactly what you defined in the xml file that created the site columns.  For instance, Field2 doesn't show up because the column definition says that it is required but the list schema says that it is optional.  Field1 won't show up because the "Name" property doesn't match in the column definition and in the FieldRef of the content type.  In fact it won't even show up in the content type.  If you delete and re-add the content type, through the interface, it creates a new content type that inherits from your content type and fixes some of the issues that were initially present.  This is why all of the fields will show up the second time around (except the fields that are incorrect in the content type definition). 

So, be careful when developing content types.  And remember, with the exception of the display name, all field properties have to match, exactly, in the three places where they are used.

Hello Everyone,

I'm very sorry for the long delay between posts.  I'm in the process of moving right now and will try to catch up with you shortly.

 Thanks

I have seen several questions, posted in various newsgroups and forums, regarding activating features when a new site is added to the site collection.  Anyone who has built features for a WSS v3 site has probably experienced the frustration of realizing that their features are not activated for any new sites that they create.  There are a couple of different ways to deal with this including Feature Stapling and Feature Event Receivers.  However, a project that I am working on required a similar function but needed to work with lists and list data at site provisioning time (the following article will explain why Feature Stapling is not ideal for this: Controlling Site Provisioning Process with a Custom Provider).  To solve this I used a Site Provisioning Provider.  Since I was already creating it for another purpose I just added a method to activate all custom features when the new site is provisioned.  Here is how I did it:

1.  Create the SPSiteProvisioningProvider

2. Create the webtempl*.xml file

     <Templates xmlns:ows="Microsoft SharePoint">
 <Template Name="Newsts" ID="10001">
  <Configuration
      ID="0" Title="Provisioned Team Site"
      Hidden="FALSE"
      ImageUrl="/_layouts/images/stsprev.png"
      Description="A site for teams to quickly organize, author, and share information. It provides a document library, and lists for managing announcements, calendar items, tasks, and discussions."
      DisplayCategory="Collaboration"
      ProvisionAssembly="Provisioner, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=9f4da00116c38ec5"
      ProvisionClass="Provisioner.SiteAction"
      ProvisionData=" ">   
  </Configuration>
 </Template>
</Templates>

 Virtually any action, that you can write code for, can be executed using this model.  Next time, I'll show some other ways in which I have used this.