11/7/2008
I'm pretty sure this does not reflect well on me, but I'll share it in case someone else can benefit from my own shortcomings:
I developed a workflow that tested fine in development, deployed to staging fine and worked there, then completed died in production.
The error: "Failed on start (retrying)" .
If you've written workflows in Visual Studio you know how frustrating that error is -- it never really retries, and the workflow doesn't usually get far enough to tell you what went wrong in the History log.
I flailed around on that one until COB yesterday. The problem: I accidentally included.NET 3.5 references in the project and .NET 3.5 was not deployed to production.
I removed the references (and associated using statements), rebuilt, and everything is fine!
Note that new projects in VS 2008 include references to Linq and new data objects by default. If you set the project compatability to .NET 3.0, VS will flag the things you need to pull out.
Of course this is not an issue if your dev, staging, and production environments are in sync! 10/16/2008As you might guess from the previous post (and my abscence here) I just did a MOSS deployment -- well, "deployment" is probably too strong a word. I installed MOSS and got it running correctly on the company's servers, set up initial department sites, My Sites for IT, and did one-hour training for IT members.
How long does that take? Here's a breakdown:
Day 1:
Acquire servers (steal one from someone who wasn't using it)
Create required security accounts
Install SQL 2005 on one server, check for updates and configure security
Install MOSS prerequisites on second server, check for updates
Install MOSS bits
Configure MOSS
Create initial web app
Set up SSP
Configure Search
Enable PDF searching
Configure Profile import
Configure My Sites
Day 2:
Meet with IT manager review progress, next steps
Apologize to person I stole server from (he was cool about it)
Apply minimal branding
Set up initial department sites, Site Directory categories
Begin holding training sessions for IT
Day 3:
Configure Search crawls of public shares
Check server health
Deploy Application Templates
Create Site Gallery with some of the templates for IT evaluation
Create project sites for SharePoint rollout in IT dept. site
Hold another training session
Day 4:
Create some initial custom site templates based on previous days feedback
Gather requirements for initial vertical applications
Work with IT to set up Active Directory groups by department
Day 5:
Begin prototypying vertical applications
Hold more training sessions
Gather/post project documents and update status
Meet with IT managers to review status
Fix any glitches and clean up
So that's a pretty good week. I think a one day install period is reasonable for a small farm configuration. You'll want to double or triple that for multiple WFEs or separate WFE and application servers.
Training is a big component, and this doesn't cover the general roll-out at all. For that I try to schedule at least one 4-hour hands-on session for groups of 10-12 users in morning/afternoon sessions (food will help attendance). Not all companies go for that, but I think it's a good minimum. 9/29/2008
This question came up Friday, I just happened to have them handy from the AppDev course I created last February. I thought I would repeat them here. There are six in all:
- Planning
- Development
- Review
- Training
- Rollout
- Support
These generic phases repeat for each smaller scale project within a SharePoint depoyment. So you would use those six steps to create the schedule for your initial deployment, then you can reuse the same steps to outline developing each of the department sites, or vertical applications within SharePoint.
The three core steps Planning>Development>Review are actually a cycle in the Agile process which are typically completed in 2-6 week a timeline. The key points to remember are:
- Don't get caught in an infinite loop. If you repeat the cycle more than once, check your stated business needs: they are probably misstated or too vague.
- Keep the turn-around short. Spending too much time in planning or development risks creating a feature set which is off-target.
- If you detect scope-creep, break the new features into another project.
Once you pass review (aka acceptance testing) train your target users in the production environment before going live. SharePoint is easy, but not intuitive, and doing a little training sets the stage for a successful rollout.
If done right, training presentations can also get your developers in front of their customers. That can improve the image of the development group (they care) and those human connections improve the feedback loop.
If you've done the training step, the rollout step is very simple: announce the deployment and monitor for issues. If things go smoothly, you can move to the support step after a week or two.
Once in support, try to record how much support is required. I guesstimate 4 hours per week per 100 users initially, then I use the actual results to adjust up or down. Example: 1000 users, estimate 40 hours/week support. Have the support folks monitor their SharePoint calls to see whether you need to slide that metric up or down.
Good luck! 9/28/2008
Hear my interview with Scott Hanselman here:
We relive the "old days" at Microsoft, discuss MCSD certification, and talk a little about the future. 9/17/2008
Boy, I have to say what a pleasure it is to be developing under Visual Studio 2008 again! I finished a gig with VS 2005 (why are big companies always 3 years behind?) and now I'm back in my own office working with current tools. Ahhh!
A couple current links in case you don't have them already:
And a tip:
The deployment files can easily get messed up in the VS 2008 SharePoint extensions. If you start getting crazy deployment errors:
- Click the Show All Files button in the VS Solution Explorer pane.
- Expand the pkg folder.
- Delete all of the files and folders in it.
- Rebuild the solution.
The files in pkg are a sort of cache built from the actual solution.xml, manifest.xml, and other project files. Deleting them clears that cache and forces a full rebuild.
Another thing: VS "cleans" manifest.xml when it copies it over to pkg. You have to manually change items in the pkg version if you want to deploy to a WebApplication (not GAC) or include code access security. Be sure and compare the project manifest.xml to the pkg manfest.xml as you near completion!
I had a bit of a backlog in Ask Jeff... but now I'm caught up. Sorry if you posted a question there and it languished. The alert I had set must have died when I moved everything to new hardware.
9/16/2008
I've posted a recent presentation here. This week, I was meeting with a customer and he started asking questions and I thought, "Hey, you should have been there last Wednesday." The PPT is up there for your benefit.
I tend to stress how SharePoint changes the way we work -- that's probably the #1 issue mid-level managers need to understand. Email is really starting to break down within businesses (I'd say it has broken outside of business, with over 90% of all email now Spam).
Moving from an interupt-driven work mode to project-centric is the most immediate and tangible benefit SharePoint provides. Take a look and let me know what you think.
Jeff 9/15/2008Another problem from the field: How do you build custom data entry forms for SharePoint lists?
There are a number of soultions, but all have drawbacks:
|
Solution |
Drawback |
|
Info Path |
Requires installed client or Forms Services license. |
|
Built-in NewItem.aspx |
Ugly, weak validation, weak lookups |
|
Data View form (SharePoint Designer) |
One-way street, weak validation/lookups, SD crashes a lot. |
|
Custom Web Part |
Generally bound to list or content type, deployed code |
|
Third-party tool |
Can't find... |
InfoPath is the Msft-approved solution, but it's hard to get in place in some clients. I think it's a fine solution, but it's just not an argument I always win.
Clearly, there is space for an alternative solution. The problem is that it is really hard. There's some partial code up on CodePlex that provides some heavily conditional classes to render the appropriate controls, but I think that approach is flawed -- if you ever got it working correctly, you'd be on the hook for any new types (custom columns) the client added. Really that's not much better than hand-coding each form on a list-by-list basis.
For now, I think the best approach is user controls -- at least thay way you can visually design what you want. SharePoint Designer should have been that solution, but it is pretty unreliable in my experience.
Perhaps a set of helper classes are in order... I'll let you know if I learn anything in that regard. 9/11/2008
I hit this giving a talk to a user's group the other day:
When I uploaded my PowerPoint presentation to my site, SharePoint quietly converted all of the links to the SharePoint site to the default AAM URL's, not the externally-facing URL's I intended.
I started the presentation, gave my talk, and at the end all of the More Information links were broken! Thank you SharePoint!
The solution I found was to use the Office 97-2003 format (.PPT) rather than the 2007 format (.PPTX) when saving the file.
Interestingly SharePoint didn't mess with other links, like the ones to Google or Microsoft that I included. This is irrational, undocumented, and completely unexpected behavior that someone at Microsoft must have put a lot of thought and effort into coding.
As a developer, I often ask customers "why would you want to do that?" I used to ask that question when I worked at Microsoft. It's never a very popular question, but it does avoid some dumb "features" some times... 9/21/2007When you create or purchase a new web part you have a choice whether to install it for all web applications on the server (in the GAC) or just for specific web applications.
Installing the GAC is the simplest approach, but it's not the one generally recommended by Microsoft due to the security risk of running the assembly in full trust.
|
|