Archive for the ‘SharePoint Conference’ Category

SharePoint Conference Notes on SharePoint 2010 – Day 3

October 21, 2009 1 comment

I am continuing my notes from the SharePoint Conference. Today I attended the Capacity and Performance Management, Externalizing BLOB Storage, and Advanced Development for Silverlight 3 in SharePoint sessions. I also did some hands on labs.

Link to my blog postings for each day at the conference.


 Capacity and Performance Management

  • Latency Improvements
    • Lighter and Faster pages
    • Early Rendering
    • WAN Optimizations
  • File Save Latency – this is a new feature that is used with Office 2010 documents and SharePoint 2010. Basically, you don’t see a save file dialog when saving large files. Instead, the file is saved to the local machine cache and incrementally uploaded to the SharePoint list. It should make for a great user experience in these situations.
  • Data Scale Improvements
    • 100 million items per search index (1 billion with FAST)
    • Tens of millions of documents/items in a single list
    • View/Query 5000 items at a time
  • Some of the 2007 limits stay the same
    • Site Collections per web application – 150,000
    • Site Collections per content database – 50,000
    • Content database size – 100 GB
  • Sharepoint Administrative Toolkit – new tools for capacity management. They didn’t give me too much details on this, so I am not sure if these are the exact names
    • Load Test Kit 2010
    • SPDiag 2010 – this is to do production monitoring
  • Logging is done in the database
    • Health data
    • Usage data
    • Gathers data across boxes through data providers
    • Extensible framework – we can build custom providers and custom reports
    • You can see the data through SQL Views, reports, Excel pointing at the SQL data, etc…
  • Different Server Architectures:
    • Single Server – for demos and dev boxes
    • Small Farm
      • around 500 users (~5 rps) and 50-100 GB of data
      • Usually 2 WFE/App Servers with a SQL cluster
      • App Servers can run on the WFE
    • Medium Farm
      • 10-50k users (~50rps) and 1-2 TB of data
      • Separating App Servers from WFE and scale out/load balancer both
    • Large Farm
      • 500k users (~500rps) and 10-20 TB of data
      • Lots of WFEs
      • Lots of App Servers
      • Lots of SQL Servers – probably 5TB per SQL box
      • Probably think about splitting your farms up if you have this situation
  • In medium or large environments, consider setting up a SQL Cluster for the content databases and a separate cluster for the logging and web analytics db. This was highly recommended.
  • Microsofts internal beta environment (this is probably larger than most organizations will need):
    • 3 General WFE
    •  1 WFE for dedicated search
    • 1 App Server for: Central Admin, User Profile Service, Metadata Management Service and Word Conversion Service
    • 2 App Servers for all the other services.
  • Recommended Server specifications:
    • 64 bit
    • WFE – Dual processor, 8 GB RAM
    • SQL Server – Quad Core, 16GB RAM


 Externalizing BLOB Storage – stores BLOB data separate from the Content DB on the file system

  • BLOBs typically account for 60-70% of total content in SharePoint
  • The official name for externalizing BLOB storage is: Remote BLOB Storage (RBS)
  • This is different from EBS (External BLOB storage), which was released in SharePoint 2007 SP1 and had issues:
  • Advantages over EBS:
    • Managed Interface
    • BLOB store scope = Content DB (verse the farm for EDS)
    • SharePoint UI = PowerShell
    • Number of Providers = Many (verse 1 for EDS)
  • Why use RBS?
    • Ability to group/store BLOBs separate from Metadata
    • Trade cost effective BLOB storage for expensive SQL storage
    • Storage management beyond SQL
  • A number of storage vendors are working with RBS – EMC, OpenText, AvePoint, Commvault, NetApp
  • RBS is a downloadable component in the SQL Server 2008 R2 Feature Pack
  • You can turn on RBS by a simple enable command in PowerShell and then the file gets stored on the file system
  • Install:
    • RBS Add in must be on SQL first
    • RBS and provider DLLs must be installed on all Web Front Ends
    • RBS must be enabled using PowerShell
  • BLOBs from SQL can be moved to RBS with a PowerShell commandlet
    • Migrates one BLOB at a time
    • You can terminate and resume the process
    • It is a live migration – no downtime required


Here are the Hands on labs I did today and my thoughts:

  • Business Intelligence – this lab dealt with Excel Services, Visio Services and PerformancePoint. I was really impressed with the new Visio Services. The Visio part of the lab started with an excel spreadsheet in a SharePoint document library. Then I opened Visio 2010. From there I could hook the data, from the excel spreadsheet, into Visio. Then I connected the data to my Visio objects. This example had a column in excel called status. If the status was 1, my server image in visio was green, if the status was 0, my server image in visio was red. After that I published the Visio diagram to SharePoint and it created a Visio Services diagram in my SharePoint site. So, I could view the Visio diagram in a web page. Then came the cool part – I edited my excel spreadsheet data (which was also in a SharePoint library) and it changed my Visio diagram automatically. This example was a quick way to show a server health dashboard controlled by excel data. But, I can think of lots of other possibilities for this new technology.

SharePoint Conference Notes on SharePoint 2010 – Day 2

October 21, 2009 1 comment

I am continuing my notes from the SharePoint Conference. Today I attended the Service Applications, Developing SharePoint on Windows 7 and the Development Best Practices sessions. I also did some hands on labs.

Link to my blog postings for each day at the conference.

Service Applications – this is the replacement for Shared Service Providers (SSP). They’ve ported all the SSP functionality (BDC, User Profiles, Search, etc…) to this Service Application methodology and then added around 20 new services. If you think of SSP as running on a single box or web application, think of Service Applications as running as a Middle Tier Service Layer. They talked about how these are not confined to a box, they are truly services now. Here are some advantages I’ve heard with Service Applications:

  • You can configure seperate databases and application pools per service
  • The Web Application chooses which services it talks to
  • Services run on an application server and this application server doesn’t even have to be on the same farm as your web application. As long as security is configured correctly, you can talk to services from an application server on another farm. This is great for Enterprise situations in which a company has multiple farms. Each farm can reuse all, or some of, the services from the main application server. A great example of this is User Profiles. If an application is running off of AD, you only need that User Profiles on one farm, even if a company has valid reasons for separating their farm structure do to other security and/or functionality constraints.
  • Application servers are load balanced out of the box. SharePoint 2010 provides a software load balancer and you can use the load balancer on applications servers (note: you can change this to hardware load balancing if you want). This means these service applications have redundancy built in if you build your infrastructure with more than one application server.
  • SharePoint Foundation (formerly WSS) can also run services – just not the ones dedicated for SharePoint 2010 (formerly MOSS)
  • This is an extensible framework. You can build custom services for your farms. This is going to be huge for the third party market.
  • The one downside to this is going to be governance (in my mind). We are going to have to control and plan where the services reside and how other farms can use them. It will change the whole structure of how we architect/plan SharePoint sites in large Enterprise situations.

Developing on Windows 7

  • There are a couple models to do this:
    • Install SharePoint, in standalone mode, on the Windows 7 machine
    • Use bootable VHDs and run Windows 7 or Server on the VHD
      • These are not virtual machines (VPC is dead), but just the VHD
      • You can only run one at a time because you choose it from the boot menu
      • You can create these VHDs from Windows 7 or from a Hyper-V machine. The presenter noted that it is easier to build them on a Hyper-V and then add them to a Windows 7 boot (if you have Hyper-V available)
      • The performance impact is negligible as long as you use fixed size VHDs
    • Use Hyper-V (this is not developing on Windows 7, so they didn’t go into this)
  • There are performance considerations for running SharePoint on your local machine. The presenter actually showed that it isn’t that bad – he showed that his machine was only utilizing a little over 4GB of memory. But, you don’t want SharePoint hogging your memory when you are not using it (i.e.: doing the regular laptop/desktop activities during the day). Here are some ways to help with the performance considerations:
    • Set useless services off (useless in terms of development). These are things like Usage Data Collection and Health Data Collection.
    • Set some services to “Auto Start (delayed)”. This delay’s the start of the service when the computer starts up.
    • Utilize PowerShell scripts to stop the SharePoint services (including all the SQL Express stuff). The presenter gave me the scripts to do this, so be on the lookout for a blog on that soon 🙂
  • The presenter showed a lot of PowerShell scripts to help development
    • You can turn on/off the developer dashboard through PowerShell. This can help performance when you aren’t developing.
    • You can start/stop services and SQL Express in order to turn SharePoint off when not in use.
    • You can set up a Visual Studio project to run PowerShell scripts. This is really cool because you don’t have to go outside VS to run scripts. It seemed a little clunky to set up (you have to set some x64 stuff in a console application). But, it is possible.
  • Here are the presenters recommended specs to run SharePoint on a dev machine 
    • x64 dual proc 2Ghz, 8Gb Ram, 80Gb HD.
    • If you are going to run lots of bootable VHDs, you might want to increase the hard drive space. The presenter mentioned the fixed size for a bootable VHD should be around 45GB or higher.

Development Best Practices –  This session described best practices that are applicable from SharePoint 2007 and how they translate to SharePoint 2010. I didn’t learn much in this presentation because it was either things that were best practices in  class=”hiddenSpellError” pre=”in “>SharePoint 2007 or things that have already been said. The general gist of this session was: develop on standalone developer machines or bootable VHDs, do unit testing and package your code in WSPs.

Here are the Hands on labs I did today and my thoughts:

  • PowerShell – I was impressed with what we can do with PowerShell. There are over 500 commands and they provide a lot of functionality. The lab started with showing how you can get an SPSite object. Then it showed how you could update an SPSite object in PowerShell. So far, this is all stuff I could do in Central Administration. But, then it showed how you can loop through sites and pipe them together to do everything at once. For example: they showed how to change all the secondary site collection administrators, on all site collections in a web application. They also showed how to create a sub-site for all site collections in a web application. This will make scripting and deployment much easier in the future. The only issue I have so far is the amount of PowerShell scripts they have and the PowerShell language (I guess I have to learn that now).
  • Advanced WebPart development – this was ok. The lab just showed how to create and deploy Visual WebParts (which is just creating user controls). The thing I noticed here was the ease of development/deployment and the speed of deployment. Even though it was recycling the application pools, the site came up fairly fast. They mentioned that they’ve been tweaking this process to make deployments more bareable for us developers.
  • External Content Types – I did a lab that showed me how to hook database data into a SharePoint list. This was all done through designer (even though you can do it in Visual Studio) and took only a few steps to set up. After hooking the list to the database table I could update the data, from my SharePoint list, and see it updated in the database. Very Cool.

SharePoint Conference Notes on SharePoint 2010

October 20, 2009 2 comments

I am currently at the 2009 SharePoint Conference where they are unveiling the details of SharePoint 2010. I’ve attended a lot of developer focused sessions today and wanted to list out some of the more intriguing functionality I’ve heard about.

Link to my blog postings for each day at the conference.

  • SharePoint can be installed on a local developer machine !!!!!!!!!
    • When I first heard you can develop SharePoint on your local machine I thought you had to point the solution at a site running on a server. But, that is not true. You can actually install SharePoint on your local machine and point your development at that or a site running on a server.
    • Machine must be Windows 7 or Vista – as long as they are x64
    • This means no more virtual machines for me (what will I do with all my external drives that hold my old VPCs)
    • The install for this version is a little different from installing on a server
      • This is just for developers and is not supported for production
      • This can only be a standalone version
      • The pre-requisites are not automatically installed like the server installation does. You have to go through the SDK and manually install the pre-requisites
      • This functionality can be disabled through a group policy if a company doesn’t want people installing SharePoint on their local machines
  • New names (of course, every new version of SharePoint means new names to remember). Here are the mappings to the 2007 names
    • MOSS = SharePoint 2010
    • WSS = SharePoint Foundation
    • 12 Hive = SharePoint root
  • The development experience is vastly improved. I thought Microsoft was just going to revamp Visual Studio Extensions. But, it looks like they built it from the ground up with all the features we have been asking for. So, no more WSPBuilder for me.
    • Visual Studio will retract the solution, deactivate the features and install the solution. But, that is just the default way it does it. You have complete control over the deployment process for the WSP it builds by changing a couple properties at the project level.
    • The deployment functionality has built in “extra” functionality for the type of element being deployed. For example:  WebParts will actually get removed from the WebPart gallery when the solution is removed. And, this is a default behavior that you can modify if you want. This new feature is called Deployment Conflicts.
    • Visual Studio has a SharePoint Explorer view. You can see your whole SharePoint structure, for a site, in this new view. And, you can dig all the way down to specific items to see their properties.
    • Deployment can be done directly to your site for development purposes. Or, it can just be exported to a WSP.
    • The whole process is customizable. I didn’t see anything that forces you to do it the “Microsoft way”. For example: They create the Manifest for the solution. But, they give you a way to “append” to their manifest (this kind of does a merge) or they allow you to completely replace their manifest.
    • The new development experience in Visual Studio 2010 is probably the most exciting thing that I’ve seen so far (other than the fact that we can deploy on our local machines). So, actually, the whole development experience is the most exciting thing I’ve seen so far.
  • Visual WebParts – these allow us to build user controls that get deployed as WebParts.
  • Elements from Designer can be exported to a WSP and imported into Visual Studio. Yeah…I can finally endorse SharePoint Designer.
    • You can export a site in SharePoint Designer by choosing an option to save it as a template. This creates a WSP file.
    • You can import that WSP file into Visual Studio. When you do this, Visual Studio gives you a UI to let you choose the elements from the WSP to import. For example: you can choose to import just a list.
    • The import functionality of the WSP creates a new project in your Visual Studio solution with features and everything
  • SharePoint Designer has site Workflows. These are Workflows that aren’t bound to a list. Why is this great… because we can finally export Workflows out of SharePoint Designer and into Visual Studio. Yes, we have deployable Workflows from SharePoint Designer – finally!
  • You can create Workflow Wireframes in Visio and import/export them from SharePoint Designer. This gives a development path from inception to delivery for Workflows. Design it in Visio, hook it into SharePoint and tweak it in SharePoint Designer, code against it in Visual Studio.
  • Developer Dashboard – this is a view, on the actual page, that is useful for Developers. Think of an output window from Visual Studio sitting on your WebPage (but with more information). 
    • Shows Database query times for everything going on in a page
    • Shows Call Stacks
    • Gives info about the page
    • Shows load times
    • This is turned off by default. You need to turn it on in stsadm or PowerShell
  • Around 500 commands were created for PowerShell
  • External Content Types – this allows us to hook up external data into a SharePoint list for read/write operations
    • We build Business Connectivity Services that have methods on them that allow us to work with external data. Kind of like a Data Layer.
    • We can bind the Business Connectivity Services to a list through the External Content type.
    • Now we can read and update data, from a SharePoint list, directly to anything (especially our database).
  • Linq to SharePoint
    • This allows us to access SharePoint list data through Linq.
    • This creates a proxy, just like Linq to Sql, to work with the data.
  • They’ve really improved lists and list performance
    • List can hold over a million items
    • Items in lists can be filtered by the metadata. Oh yeah, did I mention everything gets tagged now with Keywords. So, that is the metadata that you can filter your lists by easily.
    • You can configure list throttling to only show a certain amount of items at a time (because a webpage can’t show a million items at once).
    • Lists have cascading deletes and disabled deletes! Cascading deletes are great for Lookup lists. Finally, a little bit of integrity between our lists.
    • Lists also have Excel like validation. We can put validation on a lists through Excel like calculations.
  • The Wiki functionality is used heavily on pages now. While you can still have WebPart pages, they should become more sparsely used now.
    • Pages have content fields on them which are Wiki based.
    • You can add WebParts in these content fields. For example: I could have one line of content, a WebPart and then a paragraph. They said they dynamically add the WebPart zone now in these content fields.
  • Theres a bunch of Client OM functionality.
    • Context model to open a site client side – very useful for Silverlight and/or Ajax programming.
    • REST API – utilizing another one of my favorite Micrsoft products – ADO.Net Data Services. Yes, we can expose our SharePoint data over REST!
  • Sandbox solutions – this is a new deployment methodology for WSPs
    • First, to understand this, you have to understand that there are two models of SharePoint
      • Self Hosted – this is what we are use to. Having our servers in-house
      • Online – this is the new hosting (cloud) model for SharePoint
    • Sandbox solutions allow us to upload WSPs, inside our site, to deploy them. While this can be useful in Self Hosted or Online, it is the only way to deploy WSPs in an Online model.
    • When you create your Visual Studio solution you can pick “farm” or “sandbox” for the type of solution. This can be changed later, but they said there can be complications trying to change this after the solution is created (but it sounds like those complications are rare).
    • Sandbox solutions have less functionality (but they said it has most of the functionality we are use to).
    • Sandbox solutions rely heavily on CAS. So, if you are writing code that goes against the CAS policies, you can’t use Sandbox solutions. This seems to be a security measure so that you can deploy code in the Online model. This also seems to be the main reason to not use Sandbox solutions unless you need to.
    • Sandbox solutions also have internal controls to keep from deploying bad code. One they showed is an error message when code takes too long to execute (i.e.: trying to determine infinite loops)
    • Sandbox solutions are deployed differently than regular solutions. They were a little vague on this. But, it sounds like you upload the WSP to a solution’s gallery on the site. Then, when something in the solution gets used for the first time the solution gets deployed. I think it is intended to be a seamless deployment (i.e.: it shouldn’t affect the user’s experience – no downtime for deployment).
  • Upgrade Path – you have the choice to keep the SharePoint 2007 look or go right to the 2010 functionality and look. You can also preview what your site will look like if you choose to go to the 2010 look. Upgrades should be a lot easier now and less error prone.

So, lots of great stuff. I got a little overloaded with information today, they really revamped the product and I think it is for the better. I’ll write another blog if I learn some more new things while I am here.