The question was asked, "how hard is it to configure FAST and what does that effort give you?" The none-too-helpful answer is that with every search product you get what you give. FAST happens to have more substance so logically there will be more to configure than some alternatives, and you can get more out of it in the long run and continuously grow its ROI as you learn its ropes.
First ask what you're searching for - know your corpus. How large is the corpus, how many users will you have in years 1/2/3, is this a single farm or several geo-distributed farms, and is there non-SharePoint content to index (databases, public web sites, file shares, etc.)? Just as important is your organization's previous experience with search - do people wince when search is mentioned? Have you used search applicances? Do you have librarians, taxonomy managers, or a dedicated search curator? Have you customized or built apps on top of search? If what you have now brings the shivers, then it's easy to win friends and influence people just by delivering search that doesn't suck.
And now we arrive at the central question: Are you willing to manage search as an application? Apps get attention. When they don't work, the business has no problem kicking butts until they're fixed. So when search is more helpish than helpful, why does no one fix it? Garbage in, garbage out. Search needs to be managed as an application.
No search product is great when left with a default configuration. All are built to be improved, and along with the sexiness of the UX, this is where you will find the important differences in features. Capture that in your evaluations. FAST is better than many - it does some automatic tuning - but I would never bet a career or reputation on out-of-box FAST. No application or product does an acceptable job in the long run with a "set it and forget it" mentality. You would never treat your LoB applications this way. Nor does it work for Google.com, the Google appliances, FAST search, or SharePoint Enterprise Search. Users can scream at these products to serve better results all day (and they do), and the net effect will range from zero to nil.
Even a part-time assignment - a half day every other week - will make a sizable difference to user satisfaction. That time is spent reading feedback (you do have a feedback link on your results page, right?), investigating the search logs to see if people are finding what they're looking for (and configuring synonyms and "Best Bets" if not), and building "canned queries" and other ways to ease the experience. This is how the nifty "metadata-based navigation" in SharePoint 2010 came to be, and I see other managed search applications serve magic in their companies year after year.
So is FAST for you? It depends. If your corpus is under a million documents, your current offering is weak, and you can only afford minimal management, then out-of-box SharePoint Enterprise search is a great choice. If your indexing requirements are more demanding, or users more accustomed to a great experience, then FAST is a great choice to build on. If prepared to make any meaningful investment in people to manage search, start with FAST because it provides a great growth path for features and scalability. The question remains: To what extent are you willing to manage search as an application?
Common Sense and Opt-In: http://weblogs.asp.net/erobillard/archive/2003/05/08/6680.aspx
Eight years ago I wrote a brief piece on cookie management proposing that preferences be remembered by default with an opt-out option. The part that got the most feedback was this:
The act of remembering preferences in the form of cookies is not gathering information on surfing habits. If the issue is the perception of privacy, then educate your users about cookies. If you care about privacy, provide a button to delete cookies previously stored by your site.
Eight years later, these basic principles are reflected in the EU cookie law (http://eucookiedirective.com/) with the notable exception of opt-in vs. opt-out. People should know and care what's being stored on their machines, and as a principle transparency should always win.
The other idea worth a second thought is to make it easy for people to delete their cookies. Give them the ability to say "I'll use the site now, but to give me control over my own privacy, let me delete any cookies when I'm done."
Are these ideas still controversial? Always curious to hear.
What are Application Pools?
Application Pools are a .NET construct, and each pool represents an instance of the Common Language Runtime (CLR) executing managed .NET code. Each application pool in IIS hosts one or more web applications, and the recommendation is to stay under 10 pools per server. This recommendation was made in 32-bit days, and other considerations like 32 vs. 64-bit, available RAM, and I/O (bandwidth and disk usage) really take over as you add application pools. With some planning and the right horsepower, usage characteristics, and a healthy dose of monitoring, this is a "soft" limit and it is possible to grow beyond 10.
What happens when an application pool recycles?
Recycling is like rebooting. The process is stopped and started fresh. The CLR reloads, the assemblies in the GAC are re-read, and the application is ready to respond to requests. When the first request comes through the application takes a look at the page (aspx), web service (asmx), or whatever resource was requested, checks whether it was pre-compiled or needs to be JIT-compiled, reads the assemblies required to serve it (and does the same JIT-compilation checks on them).
Why all the JITter? In a nutshell, when you compile an assembly in Visual Studio you're compiling to MSIL (which is processor-agnostic), and not to native machine code (which is processor-specific). This JIT compilation is why the first request to a page takes longer than subsequent requests - the first request has extra work to do.
If you take the heavy-handed approach of resetting IIS (IISRESET) rather than recycling an individual application pool, there is much more to be torn down and restarted. Developers quickly learn the speed advantage of resetting single application pools, and administrators quickly learn the value of "warming up" pages so the JIT-compilation is done by the time users make their page requests.
Why do Application Pools need to recycle?
For one, an application pool recycles whenever web.config changes; this immediately enforces whatever changes are made. When you update an assembly in the GAC you also need to recycle for your new version to be "seen" since the GAC is only read when the application pool starts up - it isn't "watched" for changes. So developers tend to recycle the pools often by hand whether by IIS, a script or Spence's Application Pool Recycle Utility. To understand the other reasons we need to do more digging.
On 32-bit systems you could allocate up to 4 Gb including 2 Gb of user-addressable space per application pool, and the CLR would hit out-of-memory issues somewhere between 1.2 and 1.4 Gb of usage. This is because the CLR itself takes up a certain amount of space, let's say ~200Mb, the assemblies pre-loaded in the GAC take up space, and whatever is left is available to the application(s) in the pool. IIS lets you set recycling when memory load reaches a certain point, so ~800 Mb was a common setting for recycling MOSS applications if RAM was no issue (i.e. you had 4 Gb or more). Lower limits would be set to throttle individual pools so they might behave well together given physical memory constraints. In 32-bit days, the point of setting limits was generally to divide available memory among application pools so all could happily co-exist.
On 64-bit systems like those hosting SPS 2010, the address space becomes huge, and you'd be tempted to think "well now I can just let SharePoint use as much memory as it needs, limited only by physical memory of the server." And like most other common sense thoughts with respect to SharePoint, you would be wrong. The correct answer is somewhere between 1.2 and 1.4 Gb.
As pages are opened, objects are created and destroyed, and particularly as cached objects are created and expired, the garbage collector does its thing to reclaim memory. The same way that a hard drive becomes fragmented over time with writes, reads and deletes, so too does memory become fragmented in the life of an application pool. As fragmentation increases, more garbage collection is necessary. ASP.NET uses the large object heap (LOH) to store objects larger than 85kb, and it is particularly expensive to reorganize these when the LOH becomes fragmented (which is why I called out cached objects above). When .NET needs more memory it allocates blocks in 64Mb chunks. If memory is fragmented to the point that 64Mb of contiguous memory isn't free, an "out of memory" exception is thrown.
At some point, performance is as dependent on fragmentation and reorganizing memory as it is on the number of reads and writes. This inflection point is a good time to recycle the application pool and start over with a clean slate. So the purpose of recycling application pools for 64-bit applications is as much about defragmenting memory - in particular the large object heap - as it is about "assigning" memory per application pool.
How do you avoid JIT Lag?
There are two choices for recycling: daily at a preset time, or when memory hits a certain load. The advantage of daily recycling is that you can predictably "warm up" your application(s) once they restart. You might even script the two operations together on a timer job to minimize the chance that user requests are JIT-lagged. The advantage of recycling based on memory load is that it's less arbitrary and maximizes performance, though there is no obvious way to automatically warm up pages to eliminate JIT lag.
For a nice round-up of warm-up scripts available, head to EndUserSharePoint:
https://www.nothingbutsharepoint.com/sites/itpro/Pages/Roundup-SharePoint-Warm-Up-Scripts.aspx
Conclusions
- It's a bad idea to prevent application pools from recycling, and good to think of how best to recycle yours.
- 32-bit applications like MOSS 2007 should be set to recycle based on the maximum amount of memory you want available to each application pool but never less than 200 Mb, and anywhere from 800 Mb to about 1.2 Gb if you have RAM to spare.
- 64-bit applications like SPS 2010 are more tolerant of a daily recycle schedule, though to maximize performance the recommendation is to set the pool to recycle at 1.2 or 1.4 Gb.
- I can't believe that "JIT lag" didn't enter ASP.NET terminology a long time ago, or at least I can't find any sign of it. Death to JIT lag!
- And yes, I hope to write more this year, be seeing you!
Follow-up Q&A:
Q: How do I figure out whether memory fragmentation is an issue for me?
A: Check out this MSDN article by the guys who know this stuff best. In addition to explaining "why" in more detail, it tells you which PerfMon counters to enable. "Time spent in garbage collection" for example is fine around 10%, but should not get over 50%.
Link: http://msdn.microsoft.com/en-us/magazine/cc163528.aspx
Q: How much of a performance hit are we talking about?
A: Garbage collection doesn't happen on every page request, so the answer is somewhere between "I don't know" and "it depends." If the 50% figure in the above article is a typical symptom, that would seem to indicate 40 to 50% of your CPU cycles are not being used to respond to requests.
Other Resources:
Stefan Goßner post: "Dealing with Memory Pressure Problems in MOSS/WSS" Had I seen this I might have posted a link rather than written much of the above, but it is nice to see a post that corroborates a recommendation, in this case the 800 Mb setting for 32-bit IIS.
MSDN Article: "Introduction to Using Disposable SharePoint Objects"
The 5th Annual Toronto SharePoint Camp was last Saturday and it was another terrific success. Thanks to the TSPUG executive committee and the small army of volunteers who made it happen, and to the smiling faces of this year's 200+ attendees for making it all worthwhile.
BIG Congratulations to the recipient of our first ever Toronto SharePoint Community Champion Award: Brian Lalancette.
Brian was nominated by members of TSPUG and selected from all nominees by the TSPUG Executive for his tireless work in creating, maintaining, and shepherding the fantastic AutoSPInstaller project. You can congratulate him over Twitter with a shout-out to @brianlala, or check out his latest musings in his Lala Land blog.
Also thanks to those who came to my session on Large-scale SharePoint Architecture. This is a brand new presentation and to improve it for future audiences I'd love to hear your thoughts, comments and suggestions. While I won't be sharing the sample documents shown during the session, for the first time I've posted the original deck rather than a slide-show version. This version contains all my own annotations, so even if you weren't there you will be able to read through the speaking points on each slide. As promised, the deck contains a second presentation on infrastructure considerations for large-scale deployments for those of you wanting an IT Pro / infrastructure session. Lareger-scale infrastructure is a session of its own and I'll look into scheduling it at either the Toronto or Hamilton SPUG.
My presentation deck: Large-scale SharePoint Architecture - Eli Robillard (PowerPoint deck)
I love my Samsung Focus and I don't know why it isn't the most popular phone in Canada.
WPCentral reported today on the lacklustre support of Canadian carriers for the WP7 platform. Basically, even if you've been sold on the platform or a particular phone by a friend, review or foreign marketing (because there's none here), you're likely to be stonewalled by sales people. People who see my Focus love its speed, its easy fast UI, the fact that you can get a second battery, and the fact that you can plug in a MicroSD chip to cheaply upgrade memory. I know two people who wanted my phone, took the name down and asked for one when they went to renew contracts or sign up for service. One was told her carrier didn't offer it (fair enough) but wasn't provided with any WP7 alternatives. Now she's in the market for the new iPhone (though Apple's website for "next-day pickup" is a joke of artifical demand; she's been on it at 9pm nightly for two weeks without success while she recently moved up to #300 on Fido's waiting list). The other was talked out of the Focus by a sales rep and steered towards Android. He still likes my phone better, and now he's not sure why he got an Android.
The three problems afflicting all carriers here: staff ignorance of WP7 phones, weak or non-existent efforts at marketing, and limited selection.
Staff ignorance of the WP7 platform extends to all the Canadian carriers, and the training, commissions, advertising dollars and/or outright kickbacks that retailers receive for selling other platforms apparently don't compete with WP7 or the field might be more level.
Second, I've never seen one piece of WP7 marketing from any Canadian carrier. Not one. If Microsoft Canada is contributing marketing dollars to the carriers, they are being squandered by the most unimaginative and ineffective marketeers working in wireless today.
Third, selection is limited to say the least. On the surface it would seem okay - trepidation in supporting more than one device per carrier is no surprise. WP7 devices do appear on carrier websites. However at the kiosks, WP7 simply does not exist, at least at Telus and Bell outlets (I haven't been near a Rogers outlet lately).
Conclusion: it's hard to buy a phone you don't know about. If you're lucky enough to know about it, you still need to convince the sales people that you really, really want a WP7 phone. And then, just maybe, you can wait until they receive their next shipment x weeks from now and you haven't changed your mind in the meantime.
What's going well in Canada? Three things:
#1 for me is that the Zune Pass is now available in Canada. "Unlimited music, wherever you are." After a few days my subscription became an addiction. If you ever dreamed of being able to hear a song seconds after thinking about it, it's basically here. Whether streamed or downloaded (which also synchs it to your other devices), the catalogue is "big enough" and I love it. It's the best invention since the first MP3 player big enough to hold a whole collection. And there is no competition. I tried to get my daughter a similar subscription for her Android (her Mom got it, not my choice), and it just doesn't exist here; not through Rhapsody, iTunes or any other host, and the Napster experience requires her to synch with a PC or Mac, not directly to her phone. The iStore lets you buy but not stream. Unless I'm mistaken here (and I'd love to be wrong, a music subscription is the best gift anyone could give), there is no competition. Every Canadian music lover could be sold on this in a heartbeat. Rogers, why not offer a plan with a Focus, a 32GB Micro-SD and one-year Zune Pass? No? Fantastic product, but an opportunity squandered.
[Update 2011-11-10] Let there be competition - I discovered Rdio today. It's an all-you-can-eat music subscription available in Canada with clients for both WP7 and Android, $5 per month, and the catalogue is about as deep as Zune (~12M tracks). Trial started, fingers crossed.
#2: We have a strong developer community so there are plenty of solid Canadian apps including the Globe and Mail, Toronto Sun, a few scattered transit and taxi apps, and even a few city guides. And by the way, Mango's Scout feature works fantastic if you change the regional search settings to English-US. Scout rocks.
#3: I've had acceptable service from Rogers for my awesome Samsung Focus. Updates arrive in a reasonable time, and despite not having enough on hand or any publicity to support their launch, I eventually got one and it's worked ever since. I know someone who had one that broke, and they eventually did the right thing and replced it. Not overwhelming service, but acceptable, and in this market that's good enough.
What's your experience?
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).
Site workflow is similar to the List workflow available in 2007, but the Workflow History and Task lists are scoped to the site collection rather than an individual site, and the workflow itself doesn’t have properties to associate with or to "watch" specific items. The advantage is the wider scope that the workflow works at, and the trade-off is having to write your own monitoring for the lists and libraries. A site workflow can span libraries or sites within a collection, though you would use the workflow property bag to list associated items or documents, and would likely use event receivers to trigger workflow events from the libraries where those associated items are stored.
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.
I suspect that any choice between these will be driven by how the workflow is to be initiated. With List Relationships the workflow is still associated with a single item and the relationships drive the reach into additional items. With Document Sets you first identify the items as a set and then launch the workflow on the set. With Site Workflows you would build a custom mechanism to launch the workflow and identify the items it should apply to. If there’s another scenario, or you've encountered issues with any of these strategies, I’d be interested in your story.
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.
More Posts
Next page »