Action Steps

1. Move VM host clock forward 1 day (24hours)
2. Move VM guest clock forward 1 day (24 hours)
3. Run the Powershell command “Get-SPTimerJob | ? {$_.name –like ‘*workf*’} | Start-SPTimerJob”

What the above steps will do is to simulate a future date and then trigger the SharePoint workflow engine.  If the engine finds any past-due activities (ex:  “Pause Until ___”) then it will execute those immediately.  Using this technique you can build “Pause Until ___” workflows and still test them to ensure everything completes as expected, without having to actually wait the full time. 

Visual Studio is trying to help us out with an unhandled exception by asking about launching debug.  That’s all well and good but I didn’t write the code and have no plans to change it.

Best way to work with this is to disable the JIT (Just-In-time Debugger) by following a few simple Registry Key changes:  http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/9e6cb3fb-f8fb-4c22-8608-e521e13260ff

Visual Studio Just-In-Time Debugger

An unhandled exception (‘System.Security.Cryptography.CryptographicException’) occurred in OWSTIMER.EXE [1344]

1. Repeating table has “rowNum” with default value formula to dynamically calculate a row number.   “count(../preceding-sibling::*) + 1” can be entered with XPath mode.
2. Main non-repeating “selectedRow” field outside of the table.  Will store the user selection.
3. “Make Primary” button in the repeating table.  Action rules here update the “selectedRow” number.
4. “icon” section to show the actively selected row.  Formatting rules here show it only when selected.

Now when a user clicks the “Make Primary” the main non-repeating “selectedRow” value will be updated to have the number of the actively selected row.  Formatting rules will hide the button and display a green check mark instead.  This provides user feedback and makes for a more intuitive experience.

Also, this solution could be extended with checkbox icons for a more seamless feel.  Simply change the regular “Make Primary” button to a picture button with an image with an unchecked box.   Then update the section to have an image of a fully checked box.   There are many options to format the active/de-active row display.

   CLICK HERE to download the XSN file

[System.reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

$site = Get-SPSite "http://sitename/"
$web = $site.rootweb
$list = $web.Lists["Shared Documents"]
$caml=""
#optional filter
#<Where><Eq><FieldRef Name=""ContentType"" /><Value Type=""Text"">Form</Value></Eq></Where>"

$query=new-object Microsoft.SharePoint.SPQuery
$query.ViewAttributes = "Scope='Recursive'"
$query.Query=$caml

$items=$list.GetItems($query)
Write-Host $items.Count

$items | % { $list.GetItemById($_.Id).Delete() }

$web.Dispose()
$site.Dispose()

Highlights

• Download from http://www.microsoft.com/download/en/details.aspx?id=28802
• 60GB VHD file size
• Give it LOTS of RAM.  8GB is a starting point, 12GB if you have it.
• Homepage – very helpful menu to explore the available reports.
• PowerView, PowerPivot, Performance Point, SQL Reporting Services, Visio Data Diagrams
• Sample data (relational database, cube, team site, etc.)
• Maps in several places
• Contoso user accounts
• Master page branding and navigation

Download as PowerPoint Slides

Background

The form template contained Dot Net code.  Renaming to .CAB, extracting to a folder, and then viewing with TreeSize quickly revealed the large file size root cause.   The Reference DLL to “Microsoft.SharePoint.dll” had created a full copy of that file within the XSN template.   When working with new DLLs or third party components this might be helpful.  InfoPath is just being overly cautious by guaranteeing it has that DLL dependency covered.

Resolution

However, if you know the  DLL dependency to already be installed on the target server Global Assembly Cache then just exclude it.    Changing “Copy Local” to False quickly resolved the issue and now the XSN deploys much faster.

This also can be accomplished with Client Side Object Model, it just takes a little more code.   If you don’t have access to the SharePoint server this is a great option with flexibility to host a PowerShell script anywhere (desktop, job server, etc.)

http://itbloggen.se/cs/blogs/daniel/archive/2009/01/28/screencast-empowering-sharepoint-using-powershell-part-1.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2010/09/22/use-powershell-to-manage-lists-views-and-items-in-sharepoint.aspx

Server Side Object Model

$csv = Import-Csv .\contacts.csv
$list = (Get-SPSite "http://servername/").OpenWeb().Lists["Contacts"]

foreach ($row in $csv) {
    $item = $list.Items.Add();
    $item["FirstName"] = $row.FirstName;
    $item["LastName"] = $row.LastName;
    $item["Phone"] = $row.Phone;
    $item["Address"] = $row.Address;
    $item.Update();
}

Client Side Object Model

$csv = Import-CSV .\contacts.csv
$siteUrl = "http://servername/"
$listName = "Contacts"

$clientContext = [Microsoft.SharePoint.Client.ClientContext,Microsoft.SharePoint.Client, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]
$context = New-Object Microsoft.SharePoint.Client.ClientContext($siteUrl)

[Microsoft.SharePoint.Client.Web]$web = $context.Web
[Microsoft.SharePoint.Client.List]$list = $web.Lists.GetByTitle($listName)

foreach ($row in $csv) {
    [Microsoft.SharePoint.Client.ListItemCreationInformation]$itemCreateInfo = New-Object Microsoft.SharePoint.Client.ListItemCreationInformation;
    [Microsoft.SharePoint.Client.ListItem]$item = $list.AddItem($itemCreateInfo);

    $item["FirstName"] = $row.FirstName;
    $item["LastName"] = $row.LastName;
    $item["Phone"] = $row.Phone;
    $item["Address"] = $row.Address;
    $item.Update();
    $context.ExecuteQuery();
}

Before and After Screenshots

Here’s a site with bad colors before the fix:

Here’s the same site with smart code to give a different background-color driven by “ShowInGrid” URL:

Option #1 – Server Side – Master page with C# code

A brief snippet of ASP.Net code written in C# can be inserted into the master page.   The server side rendering will look for a “ShowInGrid” URL parameter. 

Pro

• Fast
• No client browser “blink” that JS has
• Foundation for writing other Dot Net server side code  (“smart” master pages)

Con

• Requires [web.config] edit

Action Steps

1. Open site with SharePoint Designer
2. Open Master page with Edit in Advanced Mode
3. Add the below code just before the </HEAD> tag
4. Open INETMGR and locate the website
5. Open [web.config] from the IIS website folder with Notepad
6. Add the below <PageParserPath> tag.   NOTE – be sure to update the site collection relative URL to match your environment.   Enabling this for all pages (/*) is not generally recommended unless the only people with SP Designer also are trusted developers.
7. Repeat steps #4 – #6 on each web front end server

<% if (Request["ShowInGrid"] == null) { %>

    <style type="text/css">

    /* ShowInGrid - URL parameter not found. black default. */

    body { background-color: #000; }

    </style>

<% } else { %>

    <style type="text/css">

    /* ShowInGrid - URL parameter found. white DataSheet support. */        

    body { background-color: #FFF; }

    </style>

<% } %>    

<PageParserPath VirtualPath="/_catalogs/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />

Option #2 – Client Side – Master page with JavaScript code

A brief snippet of ASP.Net code written in C# can be inserted into the master page.

Pro

• Does not require any server access

Con

• Slow
• Client browser will “blink” when JS changes the color changes from light to dark

Action Steps

1. Open site with SharePoint Designer
2. Open Master page with Edit in Advanced Mode
3. Add the below code just before the </BODY> tag

<script type="text/javascript">

    //change background color to black, unless DataSheet view

    if (document.location.href.indexOf("ShowInGrid") == -1) document.body.style.backgroundColor = "#000";

</script>

Summary

Blending anonymous and authenticated users on a single site can be challenging.  Enable anonymous read on all site content is generally not appropriate.  Anonymous users should only be granted a bare minimum set of permissions.  Enabling read on the “Site Pages” library works well to enable homepage viewing.  However, the challenge with this approach is that anonymous users then cannot “see” the root site (/) in order to be properly redirected with HTTP 302 (/SitePages/Home.aspx) to the homepage.

I recommend leveraging IIS 7 URL Rewrite to handle this direct at the IIS tier before SharePoint sees the HTTP request.   This way all root site (/) requests are correctly sent to the homepage – for both anonymous and authenticated users.

Action Steps

• Allow Anonymous on the Web Application
• Create root site collection (/)
• Enable Welcome homepage
• Enable Anonymous Access on “Lists and Libraries” under Site Settings
• Grant “View Items” permission on the Site Pages library
• Install IIS 7 URL Rewrite .MSI
• Create a new rule with Regular Expression (^$) and 302 Redirection (SitePages/Home.aspx)

Screenshots

Allow Anonymous on the Web Application

Create root site collection (/)

Enable Welcome homepage

Enable Anonymous Access for “Lists and Libraries” under Site Settings

Grant “View Items” permission on the Site Pages library

Install IIS 7 URL Rewrite .MSI

Download MSI from http://www.iis.net/download/urlrewrite and install on all web front ends (WFE)

Create a new rule with Regular Expression (^$) and 302 Redirection (SitePages/Home.aspx)

Hope that helps!