| If you get a web part error when you try to display the 2010 search results page, try installing this hotfix to .NET 3.0:
That fix enables the allowInsecureTransport attribute which is used in the 2010 Search service web.config file. |
|
My experience with Beta software is: it's best to wait as long as possible, but not longer. For me, that meant I could pretty much ignore SharePoint 2010 until today. So after about six false starts, I've got it up and running on my (now) 64-bit laptop under Windows 7 Ultimate Edition.
Here are my thoughts on setting up 2010 for evaluation and development purposes:
- Print and read this article carefully before beginnning: http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx
- Install Wndows 7, 64-bit Professional Edition or higher. The name of the edition has to match one of these exactly: "Professional Edition", "Enterprise Edition", or "Ultimate Edition". (For example "Enterprise Edition N" will fail.)
- Join youir computer to a domain if it is not already a member. Local accounts failed during configuration, even though they are supposed to be supported.
- Create a SharePoint Admin account within the domain (you can use your personall domain account if you can't create accounts within your organization).
- Install SQL 2008 R2 CTP 64-bit. You can use other editions but there's not much point if you are starting with a new Windows install (step 2).
- During the SQL install add your SharePoint Admin account as an SQL Administrator.
- Enable TCP/IP and Named Pipes protocols in SQL 2008. Do not enable VIA.
- Open SQL Management Studio and verify that you can connect to the new SQL instance you created.
- Return to the article in Step 1 and follow the instructions there.
There are a number of variations in instructions from Microsoft. I recommend not using the Vista install for evaluation. Either use Win7 or Win2008 as the target OS. The Windows 2008 install is easier, but if you're using a laptop, you'll lose features like Sleep and Resume, have trouble finding sound card drivers, etc. I did the Win2008 install first before changing my mind.
The disadvantage of Win7 is that you can't host 64-bit VMs. Theoretically you can boot directly to a 64-bit VHD under Win7, so that might not be a big deal.
Good luck and feel free to correct me if you figure out how to use local machine accounts rather than domain accounts. I might have missed something, but I sure couldn't make it work. |
|
Here's a recent email thread that summarizes my thoughts on Reporting in SharePoint.
-------------------
Hi Jeff, I have a client that wants to do list reporting. Before I dig and do a bunch of research and custom building, I was wondering if you could point me in the right direction for this? They’d like to do aggregate reporting. Like grouping items in a list by certain fields and then being able to report counts.
------------------
My response:
Access 2007 is the reporting tool of choice for SharePoint lists. Other add-on choices are SQL Reporting Services (SSRS) and Ninetex, but it’s best to start with Access.
For large lists, it’s best to organize items in folders (by month or year, etc).
---------
Thanks, Jeff. So either way you are dumping the list data to another app to do any data rollups or cubes you’d need to do the reporting?
------------
My response:
Not really “dumping” these all do real time queries. “Report” implies printable, so a client tool like Access helps. If you want an on-screen report (more of a dashboard), then there are plenty of rollup web parts – Bamboo has very reasonably priced ones. Dundas has the best charting web parts.
You can also use SharePoint Designer to create highly customized views, join lists, create master/detail views of two lists, etc. That’s easy to show, hard to explain.
One of the items you mentioned was item count – you can do that with Excel and a pivot table. We do that to chart categories of tasks (work mix) then display that through Excel Services, which is another option if you have an Enterprise License. For real reporting, Excel is limited though since it’s hard to do custom queries (you always have to start from a List View for the query).
So...depending on the customer need, I follow this sequence:
1. Single list report or chart: Excel
2. Report with complex query, multiple lists, or nice printed format: Access
3. On screen report with single or multiple lists, simple query: SharePoint Designer (note limited print formatting here)
4. More than that: add-on
I’ll usually prototype with 1, 2, or 3 to see if the 90% case is acceptable to the customer. That also helps them attach a $$$ amount to their special needs. Make sense? |
| Last August Microsoft published an amazing resource for SharePoint developers:
This is a set of patterns, practices, and guidance that everyone with a dev server and a copy of Visual Studio should read.
|
|
This question comes up from time to time: What distinguishes a SharePoint application from other types of web applications? Here's my attempt at an answer.
SharePoint applications avoid unnecessary complication by following these guidelines:
1) Store their data in the OOB content database
2) Are designed in the following order of precedence:
a) OOB
b) 3rd Party components c) No code customizations (SharePoint Designer)
d) Custom web parts (Visual Studio)
e) Custom application pages (Visual Studio)
f) Advanced customization (event receivers, timer jobs)
3) Leverage OOB features (security, search, alerts, views)
4) Consume external datasources as read-only
5) Are developed in quick cycles with the customer
|
| "The most difficult thing about SharePoint is the business it's going in to." |
|
As SharePoint 2010 looms in to view, it's not a bad idea to look back at the incredible distance we have come in the SharePoint world. I'm not talking about the platform, I'm talking about us.
For example, back in 2003 almost no one had a staging server -- development was frequently done directly in production in a site collection named /sites/test or something similar. Today, three-stage development is standard practice: development > staging > production. Some shops add a fourth or fifth level to the deployment process.
Virtuallzation is another area that we've kind of figured out. Only a year ago, doing a production MOSS deployment on a virtual platform was bleeding edge. Now, some of us consider it a best practice.
Finally, the tools and add-ons are much better now. I know that seems like a platform issue, but from my perspective it is more of an evolution of developers: we are more experienced, better at our jobs, and there are more of us now.
All that said, I think we are still evolving in the areas of workflow, user education, and applying social networking for business goals. It's nice to have room to grow! |
| I have extended the ESP Content Editor web part to include JavaScript variables for key information formerly only availble within server-side code. The .zip and more information is available here:
To see the web part at work, go here:
I'd like to hear what other variables designers need on the client side. If you have ideas, please post them here:
Thanks! |
|
This came up the other day: what is the worst idea you've seen done in SharePoint? We developed a list of five, which were too specific to describe here. However, I think they represent five general traps that enterprises can fall into when deploying SharePoint.
In order, our top pitfalls were:
1) Not enough site collections.
Increasingly, I look at site collections as a security mechanism. They keep permissions completely separate and allow you to delegate administration. Every huge site collection I've seen in production has been a nest of confusing SharePoint groups that is difficult to untangle. This is a more serious problem because it hits late in the game, once everyone is relying on SharePoint.
2) Ignore training.
SharePoint is easy, but not intuitive. All users need some training. I generally figure one half-day class to teach how to use their specific collaboration site; and one half-day class for site owners (again, using their sites). General training is less effective, since users really want examples that apply to their work, and that's hard to do in the abstract.
3) Go custom early.
SharePoint can deliver 90% of immediate needs using out-of-the-box features. Not maxing that out before attacking the very real remaining 10% delays immediate results and can result in a team that doesn't fully understand the core features very well. That's a huge on-going cost.
4) Ignore change control.
Maintaining a log of configuration changes, versioning templates, themes, master pages, and all custom components is old-hat to most software developers, but it's new ground for some SharePoint teams. If you aren't familar with these concepts, you will learn why they are important down the road, trust me...
5) Stay too long in planning.
The best solutions are adaptive, not predictive. It's impossible to know exactly how SharePoint should be implemented in an enterprise before actually doing it. Planning is important, but if it goes on for more than 30 days, cut scope and deliver something, then learn from that experience.
Bonus! Here are a three that just missed the top-five:
6) Bad branding.
It is better to do minimal branding than branding that hides or breaks features. Branding can be difficult in SharePoint, but it possible to deliver it incrementally by versioning the pieces.
7) Prohibit My Sites.
My Sites are a great training tool, leverage employee intellegence, and can easily fit in to existing email/Internet use policies. Gee Jeff, how do you really feel?
8) Move your farm.
Part of the planning process should be choosing the hardware to install on. Don't accept "We can move it later." That's a real pain in production and 100% avoidable. |
|
More notes from the field: this came up the other day -- how does one decide whether a request for a new site should be created as a sub site or as a new site collection?
First, it helps to remember that site collections and sub sites are primary levels of scope in SharePoint. A site collection is a hard boundary that has it's own set of galleries, quotas, storage, navigation, and security groups. Sub sites share all of those things within their containing site collection.
In addition, site collections are stored in a structure that is flat -- usually they are all found under the /sites or /personal managed paths. Sub sites are usually organized heirarchically within a site collection, for example: /sites/hr/benefits.
Once you understand those things, you can infer a decision matrix to help you determine whether or not a request should spawn a new site collection or a sub site within an existing site collection.
Here's a list of possible questions for such a decision matrix. Yes answers imply you should create a new site collection, No answers imply you should use an existing site collection:
Does this site request...
...potentially contain more than 5 GB of data (5 GB is my default site quota size)?
...potentially require more than 20 SharePoint security groups (or contain > 200 unique users or AD groups).
...have an owner who is capable of becoming a site administrator but does not already own other sites?
...exist as part of a business structure that might get re-organized in the forseeable future?
...require custom workflows, web parts, content types, list or site definitions, or other deployed features that are not part of your standard site package? (exclude SharePoint Designer workflows since they are no-code)
...represent a function that crosses organization boundaries?
...not logically fit into an existing site collection?
Scoring: Tally your yes/no/maybe's from above. If there are more yes's than no's the request probably belongs in a site collection, if not, then it probably should be a sub site in an existing site collection.
Feel free to add questions or submit them to me so I an append them here -- I just submit this as a starting point.
Thanks,
Jeff |
|
|