I was reminded of the functionality we implemented for a client recently that allowed the Audience Target field to appear in the Edit Mode Panel of a Publishing page layout.

You would think that it would be easier, but after lots of digging around we finally found a solution.

Firstly in the Page Layout we need to register a new reference at the top of the page:

<%@ Register
   TagPrefix="OfficeWebControls"
   Namespace="Microsoft.Office.Server.WebControls.FieldTypes"
   Assembly="Microsoft.Office.Server.UserProfiles, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
%>

With this new reference in place we can now implement the field in a standard EditModePanel way like so:

<PublishingWebControls:EditModePanel runat="server" PageDisplayMode="Edit">
   <table>
      <tr>
         <td>
            <span>
               Use if you wish to ‘push’ this content to a particular
               audience select here. Leaving it blank will make it
               available to all site users.
            </span>
            <br />
            <OfficeWebControls:SPFieldTargetToControl
               ID="Audience"
               runat="server"
               FieldName="Audience"
            />
         </td>
      </tr>
   </table>
</PublishingWebControls:EditModePanel>

Have fun!

When you set “Allow Management of content types” to Yes:

an extra item “Change New Button Order” is added to the bottom of the ECB menu for folders

This takes you to a “Change New Button Order” screen for the current folder not the document library.

You can now create logical groups of content types in separate folders, also as permission levels can be broken as folder level you can now create permissions at folder level and indirectly control who can use which content type in a document library.

The usual process occurs here within CPS in this scenario, email to the whole team asking the question and this results in a variety of response from the sensible to the ridiculous to achieve the end goal.

The sensible suggestions is as follows:

PowerShell:

Get-SPProjectWebInstance

Example Output:

We went through he normal steps of checking the service and SSP accounts, we did find that the Office Search Service had hung, but this wasn’t the problem, we checked various blogs on the web that seemed to point towards Kerberos being the problem, but this particular farm was only using NTLM. Thinking about the error “the user has not been granted the logon type at this computer”, got me thinking about logon types and failures, so a look in the Security  log turned up these errors that were coinciding with the 6641’s in the Application log.

Logon type 4 is a Batch logon, the farm account was calling this but the User Name called was for a secondary SSP that we didn’t think was used. The best way to fix this would be to give the secondary SSP account the ‘Logon as a batch Job’ right via local security policy, so preserving the principle of least rights for a service account, unfortunately we couldn’t do this so a temporary measure we added the secondary SSP account to the local admins group and the 6641 errors immediately stopped.

An unfortunate side effect of the above that that we started getting the IIS WAMREG DCOM activation errors in the System event log while not a problem in itself we fixed those as well, steps outlined here for Windows 2003 / WSS 3.0 (as this system was), just make sure ALL your accounts are in the WSS_WPG group.

Once those steps were taken all 3 event logs were error free.

If you build farms using the excellent AutoSPIntaller, then most of your work is already done as you have to plan things like your service accounts and database names for the inputs.xml file.

But what if you are called into look at a system that you know nothing about ?. in this case the equally excellent SPSFarmReport will come to your help.

The download zip file has versions for both WSS 3.0 / MOSS (32 & 64 bit) and SharePoint Foundation / SP2010 / Project Server 2010.

Once downloaded onto one of your servers with the binaries installed, simply run the appropriate executable under Farm account credentials, once ran you can delete the executable if needed.

The report output file is a nicely formatted HTML document that covers just about every single aspect of your farm configuration, this can be used to create your documentation guide, and as a timed snapshot of your configuration for future comparison.

I was using this control recently and wanted to promote the chosen person value to a list when the form is submitted, to my surprise I found that the submitted value was just a text value, not a presence aware name, so had none of the rich integration that OCS or Lync offers.

To get around this drawback I had to write a small workflow that fired when the form was submitted.

The workflow read the list value into a variable and then wrote it back to another column in the same list, but was key was to make the return field data type an Email Address.

Now we have a presence aware Name value.

Error creating site: The site template requires that the Feature {some-or-other-GUID} be activated in the site collection.

Hmm, oh well, off to Site Collection Administration and I switched on all the features I could find, but still no joy, time to crack open PowerShell.

First thing to do is find the name of the feature we are looking for, this excellent post on MSDN lists all the SP2010 features and their GUID’s.

Now we know the name of the feature we are looking for its time to get PowerShelling…

Firstly lets list all the features we have installed and activated, open PowerShell from the Microsoft SharePoint 2010 Products folder from the start menu.

the Cmdlet Get-SPFeature is the one we are going to use, this gives us a massive amount of output, so  lets add the –Site switch, so we now have Get-SPFeature –Site <myurl>,

again we have lots of output, so let use the Out-File Cmdlet to pipe the output to a text file called “features.txt”, so our command is now Get-SPFeature –Site <myurl> | Out-File c:\features.txt

now from PowerShell all we have to do is type Notepad c:\features.txt

and we have a notepad file with all our site scoped features listed, a quick search for our missing GUID shows no entry, so we have to activate the feature with PowerShell, this is simply a case of typing Enable-SPFeature –Identity <FeatureName> –url <myUrl>,

Job done.

Workflows written in SharePoint designer can be powerful, but tricky to troubleshoot if they do not work correctly.

Some workflows will complete but not perform as expected, and some will simply fail with the ever helpful An error has occurred in <Workflow Name> written to the history list.

To help us out with this is the Log to History List core action in our workflow designer Action List.

This allows us to write a message to the workflow history, and as such we could write back the value of a workflow parameter or variable that we can check on.

To illustrate this I have written a one step workflow with one Variable and one Parameter, the workflow has an Initiation Form that allows a user to select a colour.

We set the variable varColour to be the value of the colour the user selected which is stored in the parameter ParamColour , on the second line we use the Log to History List to output the value of varColour to the workflow history.

This is what it looks like, firstly we choose a colour from the Initiation Form

The workflow processes and completes, when we check the History list we can see that our message and the value of varColour have been recorded in the Workflow History list

Normally the Workflow History list is hidden from the browser, but you can change this setting in SharePoint Designer.

Checking in CA the Excel Services service application seemed to be provisioned, the settings seemed okay and the service was running, a quick check in Windows event log soon found the problem

The service application was not registered with the default web application.

As soon as we set the association, Excel Services sprang into life

Details:

70-177 – Microsoft Project Server 2010, Configuring

• Certification Type: Microsoft Certified Technical Specialist
• URL: http://www.microsoft.com/learning/en/us/exam.aspx?id=70-177

70-178 – Microsoft Project 2010, Managing Projects

• Certification Type: Microsoft Certified Technical Specialist
• URL: http://www.microsoft.com/learning/en/us/exam.aspx?id=70-178

For those who are interested in taking the exams and learning more about Microsoft Project / Project Server can I recommend that you don’t miss out on the event of the year:

Not only will various speaker sessions be available (including myself and my client!) but you will have an opportunity to try for these exams yourself for free!:

• http://www.msprojectconference.com/pages/activities.aspx

Mark the location & date in your calendar: Phoenix, Arizona (March 19th – 22nd 2012) and if you decide to come, let me know and we’ll meet up.