I don’t know about you, but I’m somewhat confused about all the hype over “cloud computing”. Don’t get me wrong, accessing services on the Internet makes sense, sometimes. What I don’t understand is how many people tout cloud computing as the silver bullet for all of our IT ills; you know, the way virtualization was supposed to solve all of our problems? That will be a different post. Back to the point. The Web 2.0 Journal has a nice enumeration of the benefits to cloud computing. First I’d like to comment on these benefits.
Blog moved: This blog has moved to http://thingsthatshouldbeeasy.wordpress.com. Go there now to see the new posts.
Tuesday, October 27, 2009
Wednesday, October 21, 2009
The Next Web: Twitter-Facebook AND Twitter-Microsoft deal confirmed
The Next Web reports that a deal between Twitter and Microsoft will be announced at the Web 2.0 Summit.
“What’s particularly unique is the deal is with both Microsoft AND Facebook and the company plans to integrate deeply with both company’s products and services, namely Bing and Facebook.com.”
Microsoft has already announced Twitter and Facebook integration with XBox Live. What’s next? Twitter and Facebook integration with SharePoint 2010? Here’s hoping. That would make for some real SharePoint 2010 cloud integration.
Tuesday, October 20, 2009
SharePoint 2010 public beta and general release announced
Microsoft issued a press release announcing the both the public beta of SharePoint 2010 and its general release. The public beta will be available November 2009, along with the public betas of Office 2010, Project 2010 and Visio 2010. The general release for SharePoint 2010 is slated for the first half of 2010.
From the Microsoft press release:
The public betas of Microsoft SharePoint Server 2010, Office 2010, Project 2010 and Visio 2010 will become available in November 2009; more information is available at http://go.microsoft.com/?linkid=9689707.
Microsoft SharePoint Server 2010 will be available in the first half of 2010. More information about Microsoft SharePoint Server 2010 can be found at http://www.microsoft.com/sharepoint.
Remember that SharePoint 2010 will be an x64-only release. That means you will need to install it onto an x64 version of Windows Server.
Watch SharePoint Conference 2009 video highlights on demand
Do you wish you were at the Microsoft SharePoint Conference 2009? Me too. Watch selected conference video highlights here:
http://www.mssharepointconference.com/Pages/videohighlights.aspx
Tom Rizzo, Senior Director for SharePoint, recaps the news and announcements that Steve Ballmer and Jeff Teper shared with the SharePoint Conference 2009 attendees. He also shared some fun facts that you might not have know about the conference.
Before diving in to the SharePoint 2010 take a moment to look back at the amazing solutions customers have built on Microsoft Office SharePoint 2007.
SharePoint Conference 2009 Opening Video
Hear what our customers are already saying about SharePoint 2010. See what they’re most excited about after trying it out and their plans for future deployment.
SharePoint 2010 Customer Excitement
Watch this short video to see SharePoint Conference 2009 come together on location in Las Vegas and learn what it takes to bring it together, such as the number of labor days and the miles of CAT 5e cable.
Watch the SharePoint Conference 2009 keynote on demand
Do you wish you were at the Microsoft SharePoint Conference 2009? Me too. But, you can watch the keynote here:
http://www.mssharepointconference.com/Pages/default.aspx
The keynote had lots of great content including loads of SharePoint demos such as the new SharePoint UI, Excel Services, Performance Point, FAST Search, and more. See Steve Ballmer, Jeff Teper, and others deliver the first true glimpses of what promises to be the best release of SharePoint ever.
Getting paid for your SharePoint software, part 4
Table of contents
Part 2
Part 3
Part 4 <--- You are here
This is the fourth part of my series on getting paid for your SharePoint software. If you have not already done so, please read part 1, part 2, and part 3.
In part 1, I discussed how you need to be able to do four things to transform a piece of software into a product that you can get paid for:
- Distribute the software
- Deploy the software
- License the software
- Copy protect the software
Of these, licensing and copy-protecting the software prove to be the most difficult on the SharePoint platform.
In part 2, I laid out two options that address licensing and copy-protecting SharePoint software:
- Licensing and copy-protecting the installer
- Licensing and copy-protecting the application assemblies
While the first option is the easiest way to get started, it also provides the least amount of protection and capabilities. The second option is what you would ultimately want to get to, but it can require a significant level of effort to implement, somewhere between several weeks to several months.
In part 3 I showed how we could use a services or cloud computing application architecture to give us additional licensing and copy-protection options beyond what I covered in part 2. Unfortunately, we uncovered new challenges that arise from this architecture, namely:
- Customer’s WAN bandwidth limitations
- Security and multi-tenancy concerns about the hosted service
- User context maintenance and single sign on (SSO)
So does that mean that a services architecture just exchanges one set of problems for another? Not necessarily. In fact, we can see that all of the issues arise from the fact that the service was hosted outside of the customer’s environment and shared among many customers. Let us examine a an alternate approach where the service the web parts access is hosted not on the Internet but in the customer’s network. My colleague Bradley Smith termed this approach as Localized Software as a Service (LSaaS).
Option 4: Localized Software as a Service (LSaaS)
The LSaaS application architecture leverages the benefits on services oriented architecture (SOA) and cloud computing application delivery models. However, LSaaS extends “the cloud” into the customer’s data center. Whereas a SaaS software delivery model requires that all service requests traverse the customer’s WAN to the service vendor’s Internet-based service instance, LSaaS instantiates one or more instances of the service in the customer’s datacenter.
The main advantage of LSaaS over traditional SaaS is that LSaaS gains the benefits that SaaS offers in terms of ease of licensing and copy protection, but LSaaS mitigates the issues that arise with a pure SaaS approach, namely:
- Limited WAN bandwidth
- Risks of multi-tenancy
- Loss of user context when invoking the service
For a more detailed description of these potential issues, please see the “All services all the time?” section of part 3 of this series. Let’s see what our licensing and copy protection options look like:
- Licensing – LSaaS licensing options are very similar to the SaaS options discussed in part 3. Additionally, LSaaS software delivery schemes also allow for service-instance-based licensing models. The idea is that each instantiation of your service running at the customer’s site can deliver a well-defined, quantifiable amount of service capacity. If the customer needs additional capacity, they will require additional instances of the service. Each additional service instance requires the customer pay an additional fee.
The key to making this licensing model work is that the service instance must deliver a predictable, quantifiable level of service capacity. How you define the capacity depends on what your service does. Popular capacity quantifiers include data storage, processing speed, processing throughput, Here are some examples of companies using service-instance-based license models to deliver their software as LSaaS:
- Black Blade Associate’s docBlock Ascend (disclaimer: I work for Black Blade)
The docBlock Ascend provides virtual document processing to the SharePoint platform. Black Blade charges a flat fee for each docBlock server appliance. Each appliance has two load-balanced processing modules. For the purposes of licensing, you can think of each processing module as a virtual document service instance. Each processing module (service instance) can process 4 virtual documents per minute. “4 virtual documents per minute” is the quantifiable service capacity per service instance.
If the customer needs to process more than 8 virtual documents per minute, they must order additional docBlock devices. There are no per-user, per site collection, per SharePoint server, or any other types of additional fees or license complexity. Simple huh? - Google Search Appliance
The Google Search Appliance (GSA) provides enterprise search capability for a variety of content sources. Each GSA is a single service instance and can index 1,000,000 documents, the service capacity. If a customer needs to index more documents, they buy more GSAs.
The SharePoint connectors for the GSA are free and even code with source code. Why doesn’t Google charge for the connectors too? The more document repositories are connected to a GSA, the faster the customer will exceed the GSAs service capacity and buy another GSA.
- Black Blade Associate’s docBlock Ascend (disclaimer: I work for Black Blade)
- Copy-protection – As with the SaaS software distribution option discussed in part 3, copy-protection is no longer needed for the web parts or other components deployed to the customer’s SharePoint farm, as these components are just the service client and should be freely distributable.
However, unlike the SaaS option, the LSaaS service instance you are deploying to the customer’s site does need to be copy protected. The best way to achieve this is to create a service deployment model that ensures that only your service is running on a given operating system instance. That way you can write management code that ensures that everything on the operating system instance, including the operating system components, conforms to a valid instance of you service. Black Blade, Google, and other vendors accomplish this copy protection by distributing their service instances as server hardware appliances.
- Level of effort - As with the SaaS software distribution option discussed in part 3, the level of effort for actually doing the licensing and copy protection is fairly low. However, architecting or re-architecting an application to use a service model can be high, especially if a high percentage of the application’s codebase makes direct calls into the SharePoint object model. There is also additional effort involved beyond that which was required for a hosted service in creating an administration and management interface for your service instances. While you can get away with running direct SQL queries and editing raw XML files to configure your hosted service, I would strongly advise creating a more end-user friendly administration experience for the LSaaS service instances you deploy to customer sites. If you are going the appliance route for your LSaaS service instances, you will need to become familiar with shell scripting, writing unmanaged (C/C++) code, and WMI.
Which option is best?
It depends. You weren’t expecting a more definitive answer, were you :-) Let me elaborate a bit. If you are just getting started with a product idea, have a product that is mostly user interface, or have limited resources to implement licensing and copy-protection components, I would suggest starting with option 1 (adding licensing and copy protection to the installer only), discussed in part 2 of this series. Once you have a product that is generating some income and you have some more resources to devote to implementing licensing and copy-protection, look at option 2 (adding licensing and copy protection to the installer and the application assemblies), discussed in part 2.
If you have some serious resources you can devote to implementing or revamping your product (say 3-6+ moths worth) and your product provides value through more than just a nice user interface, i.e. the product has a service layer, you will be able to look at option 3 (delivering the product using a SaaS model), discussed in part 3 or option 4 (delivering the product using a LSaaS model), discussed above. Although option 4 has a higher level of effort than option 3, both options require roughly the same magnitude of effort to implement. The key question to ask to determine to which service model (SaaS or LSaaS) you should use to deliver your product is: Where does the bulk of the data the service needs to process reside, at the customer’s site or on the Internet? By that I mean which location has the most data, measured in bytes, that the service needs to act upon, the client’s site or the Internet?
If the bulk of the data, again measured in bytes, resides on the Internet, then you can easily use a SaaS model (option 3) for delivering your software. If the bulk of the data the service needs resides in the customer’s site, then you should use an LSaaS model (option 4) to deploy your service. This is not just an academic exercise. I went through this decision process for each of the products we sell at Black Blade Associates.
Conclusion
This concludes my “Getting paid for your SharePoint software” series. My goal in writing this series was to encourage more developers to start thinking about getting real returns on their SharePoint expertise by monetizing their SharePoint software. A platform like SharePoint can only achieve true success if customers can procure additional platform capability as supported products, not just consulting services. With the impending release of SharePoint 2010, this is a great time to start developing sellable software products for the SharePoint platform.
Visual Studio 2010 Beta 2 has new SharePoint 2010 development tools
Download the Visual Studio 2010 beta and check out the SharePoint 2010 walkthroughs and how to’s here:
http://msdn.microsoft.com/en-us/vstudio/dd441784.aspx
Walkthroughs
- Add Feature Event Receivers
- Create a Custom Field, Content Type, List Definition, and List Instance
- Create a Site Definition Project
- Import a SharePoint Designer Reusable Workflow into Visual Studio 2010
- Import Items from an Existing SharePoint Site
- Creating a Web Part for SharePoint
- Creating a Web Part for SharePoint by Using a Designer
- Create a Custom Site Workflow Activity
- Creating a Workflow with Association and Initiation Forms
- Creating and Debugging a SharePoint Workflow Solution
- Add an Application Page to a Workflow
- Creating an Application Page
- Creating an External List in SharePoint List by Using Business Data
- Deploying a Project Task List Definition
How To...
- Add and Remove Features to a Package by Using the Package Designer
- Add or Remove SharePoint Connections
- Create a BDC Model
- Create an Event Receiver
- Customize a SharePoint Feature
The Catch
What’s the catch? The SharePoint development tools included in Visual Studio 2010 are exclusively for SharePoint 2010. What can you use to accelerate your SharePoint 2007 development today? Check out WSPBuilder. WSPBuilder is an open-source tool and add-in for Visual Studio 2008 that not only automates a lot of the manual tasks of creating a SharePoint solution package (WSP file), but also comes with lots of Visual Studio templates for SharePoint artifacts, like web parts, features, content types, etc…. There’s a great WSPBuilder walkthrough by Tobias Zimmergren here.
Then. look at SharePoint Solution Installer. SharePoint Solution Installer will take any WSP package and wrap it in a very friendly wizard interface. Next, next, next, and the WSP you created using WSPBuilder is deployed to the entire SharePoint farm.
Tuesday, October 13, 2009
Impersonation options in SharePoint code
When creating web parts, event receivers, timer jobs and other SharePoint code, I often find that I need to temporarily grant the code more permissions than the current user has. I’ve found that many developers either don’t know what options they have for user impersonation through code or are confused as to the subtle differences between the various options.
Impersonate the application pool identity
WSS V3 introduced the RunWithElevatedPrivileges method of the SPSecurity class. The RunWithElevatedPrivileges method impersonates the identity of the IIS application pool serving the current SharePoint request. The RunWithElevatedPrivileges method accepts a delegate method with no parameters. The RunWithElevatedPrivileges method impersonates the identity of the IIS application pool serving the current SharePoint request just prior to executing the user-specified delegate method. Once the delegate method has completed execution, the RunWithElevatedPrivileges method reverts the identity back to current user identity. Best of all: you don’t even need to know the username or password of the application pool identity. Here is some sample code that deletes a tasks list while impersonating the application pool identity:
Guid siteid = SPContext.Current.Site.ID;
Guid webid = SPContext.Current.Web.ID;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite site = new SPSite(siteid))
{
using (SPWeb web = site.OpenWeb(webid))
{
SPList taskList = web.Lists["Tasks"];
taskList.Delete();
}
}
});
- You code will need a the proper level of code access security (CAS) permissions in order to run the RunWithElevatedPrivileges method.
- While impersonating the IIS application pool identity will give your code the highest level of permission within the current SharePoint web application, your code will have minimal permissions within other SharePoint web applications. This usually makes the RunWithElevatedPrivileges method a poor choice if you need to access a different SharePoint web application from the one in which the code is currently executing.
- According to SharePoint deployment best practices, IIS application pool identities should have minimal permissions on the SharePoint web servers. This means that your code may have minimal access to the underlying web server while executing within the RunWithElevatedPrivileges delegate method. You may not be able to do things like write to the Windows Event logs, work with temporary files, access the registry, or any other web server resource that requires a high privilege level.
- This method was implemented in WSS V3, so it will be unavailable in WSS V2 or SharePoint Portal Server 2003.
Impersonate the application pool identity, take 2
Update: Thanks to Jonas for correcting me and apologies to Todd for misquoting him.
Todd Bleaker, SharePoint MVP, clued me in to this technique. Normally the .Net Framework System.Security.Principal.WindowsIdentity.Impersonate method accepts an integer value corresponding to a Win32 logon token. However, there is a neat trick you can use with the method: if you pass in a zero pointer (System.IntPtr.Zero), the method will allow your code to run as the identity of the IIS application pool serving the current SharePoint request. As with the RunWithElevatedPrivileges method, you do not need a username or password to do the impersonation. However, unlike the RunWithElevatedPrivileges method, you can use this technique with WSS V2 and SharePoint Portal Server 2003. Here is the same code as in the previous example, but altered to use this impersonation method:
private WindowsImpersonationContext ctx = null;
ctx = WindowsIdentity.Impersonate(System.IntPtr.Zero);
using (SPSite site = new SPSite(siteid))
{
using (SPWeb web = site.OpenWeb(webid))
{
SPList taskList = web.Lists["Tasks"];
taskList.Delete();
}
}
if (ctx != null)
ctx.Undo();
- You code will need a the proper level of code access security (CAS) permissions in order to run the impersonation, WSS_Medium, according to Todd Bleaker’s article.
- While impersonating the IIS application pool identity will give your code the highest level of permission within the current SharePoint web application, your code will have minimal permissions within other SharePoint web applications. This usually makes impersonating the application pool identity a poor choice if you need to access a different SharePoint web application from the one in which the code is currently executing.
- According to SharePoint deployment best practices, IIS application pool identities should have minimal permissions on the SharePoint web servers. This means that your code may have minimal access to the underlying web server while executing within the RunWithElevatedPrivileges delegate method. You may not be able to do things like write to the Windows Event logs, work with temporary files, access the registry, or any other web server resource that requires a high privilege level.
Impersonate a named user account
While you can use the System.Security.Principal.WindowsIdentity.Impersonate method to impersonate the Local System account, the real purpose of the method is to allow you to impersonate named user accounts, such as mydomain\jsmith. The .Net Framework has a nice model for handling the impersonation context once you have a logon token but is somewhat vague on the mechanics of actually getting logon tokens. My RunAs in C# article with source code details how to get these elusive logon tokens and execute your code in the generated impersonation context. The article wraps the LogonUser Win32 API. The main benefit to this approach is that you can execute code as any user you want, as long as you know the user’s username and password. This includes doing highly privileged operations within SharePoint, SharePoint farm servers, or any other server on the network. Here is a code sample that executes a file move using user-supplied credentials:
BlackBlade.Utilities.SecurityUtilities.RunAs(delegate()
{
File.Move(“local_file”, “network_file_location”);
},
“a_username”,
“some_password”);
What are the catches:
- You need to know the username and password of the account you want to impersonate.
- Accessing the Win32 API can generate non-intuitive error messages and be tough to debug.
- Finding a secure place to store the username and password of the account your impersonating can be tough. I recommend looking at the MOSS 2007 SSO infrastructure.
Impersonate the Local System Account
Normally the LogonUser Win32 function used to get logon tokens for .Net impersonation requires a domain, username, and password to get a logon token. However, there is a neat trick you can use with the method: if you pass in “NT AUTHORITY” for the domain and “Local System” as the username, the method will allow your code to run as the Local System account. You do not need a password. The Development Hole blog has a great article with code detailing how to impersonate Built-In service accounts. The Local System account can do pretty much anything on any SharePoint server in the farm. As with the other impersonation methods, you will need to manually revert the impersonation context. Here is some code that uses the Impersonate method to write an entry to the local SharePoint server’s Application event log:
using (Impersonation imp = new Impersonation(BuiltinUser.NetworkService))
{
this.EventLog.WriteEntry("This line would throw an exception for most SharePoint users or even most application pool identities");
}
- This method always impersonates the web server’s Local System account, regardless of in which SharePoint web application the code is running. This can make it very difficult to track which web application is accessing the web server’s resources.
- In most cases, the Local System account will not have rights to any network resources, including SharePoint content or administrative tasks. While you’ll be able to do anything you want on the local web server, you will not be able to engage in any SharePoint-related activities.
Thursday, October 08, 2009
VMware Workstation networking not working in Windows 7
I just upgraded my Vista x64 computer to Windows 7. When I started VMware Workstation 6.5.3 for the first time after the upgrade and launched a virtual machine, VMware displayed the following error:
The virtual network drivers on the host are incompatible with the installed VMware application. Expected version 5. Please reinstall the product.
The error sounds a lot worse than it actually is. Turns out that all I had to do to get things working was run a repair on VMware Workstation. You will need the VMware Workstation installation program. Do not run the repair option from the Programs and Features section of the Windows 7 Control Panel. If you do, you will receive a message box telling you to run the original VMware Workstation installation software, and the network repair will not complete properly.
The repair process will take a while to complete, about 15 minutes on my computer. The installation software will remove and reinstall all of the virtual drivers, including the networking, on the host computer. You will need to restart your computer after the repair is complete.
Once you restart your host computer, you may get an this error message:
Device driver software was not successfully installed.
This is actually referring to the two network drivers VMware installs. I’ve only seen this on one computer so far, but as near as I can tell, there are no adverse affects yet.