Eli Robillard's World of Blog.

I had the question today of whether SharePoint 2010 supports  workflow on multiple items, since Groove's workflow apparently supported multiple items and that model disappeared when Groove Workspaces were amalgamated into SharePoint Sites and SharePoint Workspace (the client utility). It's a great question, the short answer is that yes, it's possible. You could brute-force it in 2007 and that strategy should still carry over to 2010, and 3 new features (that I can think of) support multi-item scenarios more easily in 2010.

First, the brute-force method in 2007: While each workflow is associated with a single list item, there is also a property bag available on the workflow where you could store references to additional items, or a reference to a second workflow running in parallel, depending on how the processes for each document need to interact. The caveat is that this strategy is both complex and code-intensive; in addition to the code necessary for the two workflows to work in synch and respond to events on the other, you should consider whether your scenario requires a housecleaning process to clean up orphaned processes or items, or any similar indirect "exception handling."

There are three new constructs in SharePoint 2010 I can think of that make it easier to build workflow for multiple documents: document sets, site workflow and list relationships. Document sets are a new way to associate documents with each other; for example a set of project deliverables (e.g. budget, requirements, project plan and design). Document Sets are a new content type (inheriting from folder), and any workflow associated with a Document Set will apply to all documents within each set. In this scenario a constraint is that the documents remain "near" each other since the sets do inherit from the folder type. Also note that Document Sets are a SharePoint Server (SPS) 2010 feature; they are unavailable in SharePoint Foundation (SPF).

Then you have List Relationships. You can now create a foreign-key relationship between columns in two lists. It should then be simple for a workflow on any given item to get a reference to a related item and “do something” with it.

Fellow Infusionite Oguz Demirel just published a super-cool CodePlex feature that makes any SharePoint library drag-and-droppable, introducing: Drag & Drop for SharePoint.  

The Codeplex page has screen shots and all that, but I have to rave about the simple coolness of it all. Just like in Explorer you can draw a box around the files to pick. Then you can either drag them: onto a folder in the library, to another library in Quick Launch, or to a Parent folder by dragging them up to the breadcrumb. If there's a valid destination on the screen, you can drag 'em there. Now that's cool. It's all done with JQuery, and once you try it you'll wonder how you lived without it. Enjoy!

When I started putting together my standard virtual machines for development and demonstrating SharePoint 2010, I wanted to have a domain controller that I could share and use for any new image. That way I don't need to continually recreate my service accounts and test users every time, which means the effort I put into creating AD groups and populating user properties is also re-used.

Why server core? Server core flavours of Windows Server don't provide a UI, and are usually used to build specialized, minimal servers to provide a specific capability. The domain controller described here runs fine with 512 MB RAM and though I've assigned it a 10 GB hard drive my own uses only about 5 GB of storage. They aren't used more because it's a pain to install and configure services; without a UI that means the action is at the command-line. By providing the steps here you can get past the pain, and AD thereafter is managed from any other Windows Server (like a SharePoint server) using the AD Management UI you're used to.

I intended to post this months ago and haven't had time to "flesh it out," but a few people have asked and I'd rather not delay it further. I did find a few references around the web on how to build a server core DC, but all seemed to skip something or other, so this is actually the most complete (or was when I wrote it). If you just want a regular (i.e. non-server core) DC then go check out this post from Kirk Evans: http://blogs.msdn.com/b/kaevans/archive/2010/04/17/creating-a-windows-server-2008-r2-domain-controller.aspx

Some steps are written like a pseudo-batch file with comments or instructions marked with "REM," while other parts are more step-like. I built mine on VMWare, but you could execute this on any virtualization platform or even bare metal. A few note: "Type this command, or replace the quotes and spaces after you paste it." If you don't do this, then I guarantee that some commands will fail. As near as I can figure, this is because of internal conversions between character sets when cutting and pasting.

Here we go!

These steps build a server with:
- Windows Server 2008 R2 Server Core
- DNS Role
- Active Directory Domain Controller (DC) Role
- IP address: 192.168.5.2 (you can use your own, just be consistent)
- Gateway to the internet via host machine at IP: 192.168.5.1 (ditto)

Create a new VM
Install Windows Server 2008 R2 Server Core

REM Allow terminal services
cscript C:\Windows\System32\Scregedit.wsf /ar 0

REM Allow Remote Desktop
Note: Type this command, or replace the quotes and spaces after you paste it.
netsh advfirewall firewall set rule group=”Remote Desktop” new enable=yes

REM Allow Remote Administration
Note: Type this command, or replace the quotes and spaces after you paste it.
netsh advfirewall firewall set rule group=”Remote Administration” new enable=yes

REM Set newname in the next line to the preferred machine name:
netdom renamecomputer %computername% /newname:CoreDC

REM Restart
shutdown /r /f /t 0

REM Note the default gateway shown by this command, it should match your host machine's IP
ipconfig /all
REM Note the interface name shown by this command, you will use it to set a static IP
netsh interface ipv4 show interface

REM Update this command with the connection name, preferred static IP, and gateway (host) IP
REM Note: Type this command, or replace the quotes and spaces after you paste it. If not an error message is displayed.
netsh interface ipv4 set address name=”Local Area Connection” source=static address=192.168.5.2 mask=255.255.255.0 gateway=192.168.5.1 1

REM Check that the static IP took effect
ipconfig /all

REM Add DNS and DC roles with a new forest, all machines should be Windows Server 2008 or above
dcpromo /unattend /InstallDns:yes /dnsOnNetwork:yes /replicaOrNewDomain:domain /newDomain:forest /newDomainDnsName:contoso.dev /DomainNetbiosName:contoso /databasePath:"c:\Windows\ntds" /logPath:"c:\Windows\ntdslogs" /sysvolpath:"c:\Windows\sysvol" /safeModeAdminPassword:Contoso123 /forestLevel:3 /domainLevel:3 /rebootOnCompletion:yes

Create and configure additional servers
- Install Windows Server 2008 R2
- Install updates
- Set an IP address in the same VMWare subnet (e.g. 192.168.5.x)
- Use your new DNS/DC as the DNS server
- Update the machine name and connect to the infusion.dev domain
- In VMWare, add a second network card using NAT. You may need to adjust the DNS settings to match those used by your host machine.
- Open a browser to confirm that you have internet access

- Install the Remote Server Administration Tools (RSAT) on at least one machine
- Control Panel, Programs and Features, Windows Features, Add Features
- Expand Remote Server Administration section, select AD and DNS checkboxes
- A restart will be required

Wow, this Saturday offers 21 sessions in 3 tracks, all for free. Given the billable rate of this speaker list, this has to be the best bargain you'll see for a while. And I'm going to go ahead and reveal a secret here - attendees at SharePoint Saturday will be eligible for a great discount on the SharePoint Summit, coming to Toronto this January 31 through February 2. The only catch? You need to attend to get the discount. But I'm sure you wnat to be there anyway, this is a world-class event and a great way to kick-start or build on your SharePoint knowledge.

I'll be there Saturday afternoon with a session I call "Strategies for building SharePoint capacity." This is for managers, sponsors, development and test leads, and perhaps the IT Ops leads who manage the pipeline. The focus is on building the team and pipeline - what the people in each role can expect from each other and what each is responsible for, in order to make the whole process work. Like many things this harkens back to the mantra of dog trainers: “Don’t train dogs, train owners.” This session is training for SharePoint owners. Learn what great SharePoint teams look like, understand the planning and capabilities that make it so, and how to build solid teams to manage both its hosting and your solution delivery pipeline. I'll also be providing examples and anecdotes from recent projects.

Thanks to Kanwal and his dedicated crew of volunteers for putting this together, and to all the sponsors for making the day possible. Afterwards I expect we'll head across the street from Microsoft Canada to the Firkin to decompress over a SharePint. Register today, space is limited and it's rapidly filling up. See you Saturday!

SharePoint Saturday Toronto Registration 

Today the fix shipped to remedy a cryptographic ASP.NET vulnerability. The update is listed as Important, and it is strongly recommended that this security update be applied to all IIS servers including those hosting SharePoint and other ASP.NET applications. Though the greater risk is to public-facing servers, all servers should be protected.

The fix was announced as a Security Bulletin:

http://www.microsoft.com/technet/security/bulletin/ms10-sep.mspx

A webcast will be held this afternoon to describe the vulnerability and to field questions:

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032464130&Culture=en-US 

The update can be downloaded here (dated Sept 27, 2010):

http://www.microsoft.com/downloads/en/results.aspx?freetext=Security+Update&displaylang=en&stype=ss_rr&nr=10&sortCriteria=Date&sortOrder=Descending 

Here's to a safe week! Big thanks to all product teams involved for staying on top of this, providing incredibly fast guidance to keep customers safe, and now a permanent solution.

On Friday an ASP.NET vulnerability was announced at an Argentine security conference, Microsoft posted Security Advisory 2416728 within a few hours, and by early Saturday morning Scott Guthrie described steps to mitigate ASP.NET sites against the vulnerability. Scott also posted a FAQ about the vulnerabilty that describes steps being taken towards a permanent solution, and how to detect attacks by monitoring server logs. Monday the SharePoint Products and Technologies team posted Steps to protect SharePoint 2010 sites from the vulnerability.

This post answers a few questions that colleagues and I had after reading through those links.

Q: What about SharePoint 2007?  

A: The WSS 3.0 and MOSS 2007 guidance would be nearly identical. One difference is that the application page to report the generic error will be stored in ...\12\template\layouts (or a subfolder of this) rather than 14.

Important Updates, Sept 21 and 24: The product team changed its guidance to explicitly include WSS 3.0 and MOSS 2007, and published an extra step that removes the resource loader from the application [Link].

Q: What if I want my company's branding on the error page?  

A: You can customize the error page to include branding, though it would be wise not to include any SharePoint controls or additional assembly references. If you must include branding then hard-code it; references to the images folder (e.g.: /{SharePoint Root}/layouts/images/{myImageFolder} ) are fine. What you must avoid is introducing any elements that rely on user context or availability of the API (breadcrumbs, etc.) that might cascade their own exceptions or provide further information about the nature of the root exception. The sample error page includes a random timer to vary page load times in order to obfuscate the nature of the exception. Note that the page is otherwise dead simple and does not reference any API except to produce a random number.

Q: What if I rely on error codes for load balancing or analytics?  

A: Once a patch is released that resolves the underlying issue, you will be able to reset web.config files to serve more granular errors. In the meantime, look into your application paths and make sure nothing is there that would pose a risk if it walked out the door. If against all guidance you have credentials hard-coded in web.config or custom code, perhaps now you understand why this is considered bad form.

Q: What if I follow best practices? I already encrypt all secrets in web.config, don't have anything to hide in ViewState that users shouldn't see, and monitor for trouble using the Dynamic IP Restrictions module in IIS 7 (or some other protection from DoS attacks). What's my risk?

A: If your security and practices are such that all the files in your web application could walk out the door without exposing any vulnerabilities, then you've done a great job, and based on what I know about the vulnerability, your risk is minimal. If you have any doubt, follow the prescribed steps to protect your environment until the permanent fix is released.

 As near as I can tell, this vulnerability should only be of concern to administrators and developers who do not follow well-known security practices. As the advisory says: "An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config." It should go without saying that no secrets should be available through ViewState or web.config. Only encrypted secrets (e.g. database credentials) should ever be stored in web.config, and your applications should be developed to remain secure even if full source is available or the assembly compromised.

Thanks to all the product teams involved for their incredible response, and fingers crossed for a speedy resolution.

Apologies all, notification was to go out sooner but apparently we're having technical difficulties so please help spread the word:

The May meeting (tonight) is cancelled, leaving you free to enjoy the summery Toronto evening. Enjoy!

Next month on Wednesday, June 16, TSPUG is back with not one, but two, count'em two presentations: First up will be Matthew Pakula from AvePoint talking about their terrific tools for MOSS 2007 and SPS 2010. Then I will reveal the secret toolkit I use to help companies build out SharePoint delivery centres in a session preliminary titled "How We Build SharePoint at Infusion." Basically I'll distill the best practices and tools gathered from Microsoft, the history of project management, and years of implementation, development and maintenance projects. 

And yes, TSPUG.com is down. It too will return and we want to come back on SP2010, but being a non-profit org we're still working out how to cover the licensing so all is legit. In the meantime, tune into the Twitter feed at http://twitter.com/tspug for all the latest.

SharePoint 2007 was the best demo-ware ever. It’s like going to the pet store and seeing a great dog that does backflips all kinds of tricks – and it really is a smart dog and it does all those tricks – but when you get it home you realize that what you need is a dog that gets the paper. SharePoint 2007 can be trained, but is fundamentally a platform where Microsoft's priority was to get the infrastructure right – to make it trainable and extensible. Because it was great demo-ware it caught on like nothing ever before and became a billion dollar product. But adapting it to specific uses did take serious effort because the priority was the infrastructure rather than the tools to build solutions on that infrastructure. Thankfully Microsoft did spend time explaining how to train it (a lesson they learned after SPS 2003), but the effort was a significant part of delivery. 

When building SharePoint 2010, the infrastructure was there so Microsoft focused on making it easier for people to build solutions. You still need a vision of what the solution will be and a design process to work out the details, and you still want people who deeply understand the platform in order to develop effective solutions. But the development story is now much more about configuration and less to do with programming. In both cases, both configuration and programming are supported with much-improved user interfaces, especially for common scenarios.

A gut estimate of the difference in effort goes like this. Counting "lines of code" and "effort of configuration" solutions consisted of ~50% configuration and 50% code with SP&T 2007, and programming took up 80% of the time. With SharePoint 2010, the same solutions can be composed with 90% configuration and 10% code, and on average programming will account for about 20% of the build time.

To consider an actual project, we delivered a knowledge management solution using MOSS 2007 including customized collaborative sites and a document repository. The bulk of programming time was spent on: custom field types (some cascading) to pull lookup values from a web service, rewriting content type propagation (Soren's code and Gary's extension do not cover important cases), building custom web parts to aggregate information from disparate sources, building workflows to approve and provision new sites, writing event receivers to tag and route documents, and building a custom site directory to display the sites a user belongs to. Thinking through these components, easily 90% of it would now be covered by configuration, and a 2010 solution would take about 50% less effort to maintain and update post-launch.

It’s hard to say how much shorter delivery time will average. If lines of code accounted for 80% of time before and 20% now, and a “unit of configuration” takes half the effort of development, then all-code would be an index of 1 (= 100% * 1), 2007 presents a relative effort of .9 (= 20% * .5 + 80% * 1) and 2010 falls to .42 (= 80% x .5 * 20% * 1). That's about half the effort (or resources). The architecture and design cycle should change little, if at all. Prototypes are more likely to provide a starting point for development (e.g. Visio flowcharts and SharePoint Designer workflows can now be imported to Visual Studio for finishing). Branding will change little, though there will be less redundancy (e.g. no additional effort to rebrand application pages). All work still requires testing and a feedback loop with sponsors and users.

Remember that these are all from-the-gut, invented numbers and non-scientific equations, and what counts are our real experiences and projects just now underway. So what do you think - close or far off? Was your index lower for 2007? Do the SharePoint 2010 components better support your scenarios and if not, why?

This year we plan to add one room and expand the number of sessions slightly from about 20 to about 25. As in past years while everyone is welcome to submit more than one abstract for consideration, each speaker will be selected for a single session in order to involve more people and encourage first-time speakers. Also as in past years, we’re looking for more content for attendees representing IT Pro (server administration), Architects, and "The Business." You can learn more about our tracks and audiences in the Call for Speakers document.

If your company is interested in sponsorship opportunities during the TSP Camp, please contact me through this site and I will connect you with sponsorship chair Ruven Gotz. Registration will also begin this month, stay tuned for details.

We do not provide travel or accommodation, but do provide lunch, a speaker shirt, local fame for a full hour, and a lifetime of fond memories. Hope to see you there!