Configuring Search in SharePoint 2013 can be a tricky process that is best accomplished via PowerShell scripts. For starters, those messy database names with GUID's in them that get created from UI provisioning are just hideous, but the real issue is that a proper topology (meaning search components running on more than a single machine) can only be deployed via PowerShell cmdlets. Despite our best efforts to script the entire process and avoid the kind of small mistakes that lead to endless hours of frustration, it's inevitable that some small setting or configuration step will crop up that creates a giant headache.
Take, for example, the new "SPSearchDBAdmin" role. This role, which didn't exist in 2010, is added to each search database when it is created in SQL server. If you are following best practices and assigning service accounts for search operations (one for administration, one for crawling, and neither should be the SharePoint Farm or Admin accounts), the account you assign as the Search admin will be added to the SQL logins and given the "public" role. That's all well and good for least privileged purposes but that role alone is insufficient for the Search application to function. Unfortunately, there's no warning about this when the Search service application is created – provisioning will succeed but nothing really works. In order to kick Search into gear, you first need to assign the "SPSearchDBAdmin" role to the Search admin account in SQL server.
Assigning the SPSearchDBAdmin Role in SQL Server Management Studio
Also bear in mind that the Search admin account requires read/write permissions to the folder in which the index files reside. As this account should *not* be a local administrator it's very likely that it won't have access to the folders that hold the primary and replica index files. Be sure to assign the appropriate permissions on each server in the topology which contains an index partition (the default location is "C:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Applications" which, ideally, should be changed as part of the provisioning process). Possible error messages which indicate your search admin account may not have the correct SQL or folder permissions include:
"Content Plugin can not be initialized - list of CSS addresses is not set."
"Unable to retrieve topology component health states. This may be because the admin component is not up and running"
"Topology activation failed. No system manager locations set, search application might not be ready yet"
"Could not access the Search database. A generic error occurred while trying to access the database to obtain the schema version info."
There are a lot of blogs, forum posts, and articles with all sorts of advice on how to deal with these errors, most of which prescribe repetitive un-provisioning and re-provisioning of service applications. Although those solutions may apply to your environment at some point, before going down that road first ensure that the Search admin account has the proper database and file permissions, as no amount of provisioning will overcome basic security limitations.
(Note: For a good walkthrough on Search provisioning via powershell, refer to this post from Ryan Bushnell and the Search cmdlet reference on TechNet)
For several years now, Steve Smith and the gang at Combined Knowledge have hosted one of the best SharePoint conferences anywhere in the world. Under various guises as "SharePoint Best Practices Conference", "International SharePoint Conference", or "SharePoint Evolution Conference", this annual London event is something that both the attendees and the speakers look forward to – the information is top-notch, the venue perfectly suited to a mid-size event and the entertainment is out of this world. Unfortunately, due to the timing of the Microsoft SharePoint Conference in Las Vegas this year, the event couldn't be scheduled during April and the Queen Elizabeth II Conference Centre is a much sought-after location, being just across the way from the Houses of Parliament and Westminster Abbey, so a later date was logistically infeasible.
So what to do? Well, if you're Steve Smith, you don't just throw in the towel and wait until next year. You take the show on the road! Instead of bringing a bunch of people to a single location, you pack up the whole shebang into a fleet of coaches and send it all across the United Kingdom for three weeks. A crazy idea, to be sure, but no more crazy than putting on a three day event that starts on day one with dozens of top-notch IT Pros and Devs working independently and ends on the final day with a complete set of end-to-end solutions (which we managed to pull off at the International SharePoint Conference 2012 in case you missed it). So why the not give it a go?
And that's exactly what we're going to do. Starting on June 9th, 2014, the SharePoint Evolution Roadshow kicks off in Cardiff, Wales, for a full day jam-packed with sessions from many of your favorite speakers in the global SharePoint community. The show then moves on to London, Cambridge, Birmingham, Nottingham, Manchester, Leeds, and Newcastle, then swings up to Scotland into Edinburgh and Aberdeen, finally wrapping up in Belfast and Dublin on the 24th & 25th of June (I'll be joining the tour for the last portion up north). No matter where you live in the UK an Evolution show is going to be in your neck of the woods this coming June (unless you reside near Fair Isle or Penzance, that is). Even better, the lineup rotates from location to location with only a few speakers going to every city on the tour. So the content will change at each venue, giving you an opportunity to attend more than one event without much overlap. How cool is that?
But the best part is the price. It's only £99 per event! The average cost of a major conference is over £250 per day, making this one of the most affordable learning opportunities anywhere. You just can't beat it. So get out your calendars and AA road planner – it's time for some SharePoint, Evolution style, like nobody else can do it.
For more information and registration details, visit the SharePoint Evolution Conference website.
Today the good folks at Combined Knowledge and myself received some excellent news – our Support+ app was approved for the SharePoint Store and is now available for download. Although I've been working on SharePoint apps since mid-2012 (yeah, it really has been that long) this is the first commercial app that I've had published in the store. Fellow SharePoint MVP Steve Smith and his crew in the UK did a tremendous job putting all the content together and really making the app look great. My challenge was to take what they had built and turn it into an app for both Office 365 and on-premise SharePoint 2013. There were a number of challenges involved, most notably the limitations of the store licensing model and differing capabilities in the two deployment models, but in the end it was a valuable learning experience.
If you have an Office 365 tenancy Support+ is definitely worth checking out. The app is free and contains a wealth of content that you can utilize with no time restrictions or other limitations. Feel free to take it for a spin and kick the tires. We hope you enjoy it. While you're in the store, take a few minutes to check out some of the other great apps that are available. If you're a SharePoint developer, now is the time to get on the bandwagon and create the next best app the world has ever seen!
Take the trouble out of troubleshooting.
The next SharePoint Conference is almost upon us. From March 3rd through the 6th of 2014 the greater SharePoint community will be descending upon Las Vegas once again to collaborate, communicate and commiserate. This year I'll be going a bit easy on the speaking so I can spend more time networking and getting a feel for what's happening out in the real world but I do have one session on the agenda:
Developing an Intranet on Office 365
Learn how to leverage the power of the cloud to build dynamic, informative and engaging Intranet solutions with Office 365. Get real-world guidance and best practices for driving user adoption and engagement through powerful features like cross-site publishing, metadata navigation and search-driven content, along with proven techniques for custom branding, interface extensions, disaster recovery and lifecycle management.
For the rest of the event I'll be lurking around the exhbitor hall and, of course, at the various parties and social gatherings. I'll be going back to my roots a bit and spending more time in the vicinity of the Office/SharePoint kiosks this time around. I'm also looking forward to engaging in conversations around the 2013 app model, cloud development, SmartTrack, and some exciting new offerings from partners such as AtomOrbit, Combined Knowledge and The SharePoint Shepherd. Keep an eye out for the hat and feel free to say "Howdy!".
P.S. - If you haven't registered yet, get to it. This event will almost certainly sell out and you don't want to miss it!
UPDATE 3/5/2014: Thanks to everyone who attended the session. The slide deck can be viewed on SlideShare and the code samples can be downloaded here. Viva Las Vegas!
Take the trouble out of troubleshooting.
With the release of the app model in SharePoint 2013, and all the subsequent marketing hype surrounding Office 365 and the determination of Microsoft to push their customers into the cloud, many have predicted that the end of full-trust farm solutions was nigh. For a while, especially if the rumors swirling within the greater SharePoint community were to be believed, it even seemed as if on premise deployments were going to become a thing of the past. Thankfully, after thoroughly confusing the market with mixed messages and an over-emphasis on all things cloudy, Microsoft has finally put these rumors to rest and, with the announcement of the impending Service Pack 1 release for 2013, made it clear that SharePoint as we know it is not going away anytime soon.
So what does this all mean for developers? Should you continue to invest in full-trust, on-premise solutions or move to the new app model? The answer, of course, is "it depends". It all comes down to your requirements – there are some scenarios where apps are the right answer and others where full trust solutions will be more appropriate. But let's be clear about one thing – isolated code execution via remote interfaces is the future of SharePoint development. Period. That doesn't mean you need to throw out all your existing code and start over from scratch but it does mean that you need to start thinking about, and planning for, a new way of doing things. Getting a head start on it now will pay dividends in the long run so there's no reason to delay – if you're not yet familiar with building SharePoint apps, then now would be a good time to get started.
But the question still remains – if both models are viable then how do you determine which is the right one? The first step is to understand the direction your organization is heading. If you are a small, nimble company with a significant investment in cloud technologies already, then odds are you will soon be moving to Office 365 for core collaboration features. This means you should start designing all your future solutions as apps, since that will be the only model available to you in the cloud. However, if you are a larger organization that doesn't move as quickly, or you have good reasons for keeping your collaborative environment in house (either on your own hardware or in hosted by a managed service provider), then you have a lot more to think about. Knowing that you will continue to have an on-premise deployment of some sort makes it easier to chart a course for supporting existing full trust solutions but what about green field projects? It's easy to keep doing what you already know how to do but what if the organization adopts a hybrid approach sometime in the near future? How would that impact your solution architecture? Could you refactor into an app without causing massive delays or cost overruns?
In many cases, the application requirements themselves dictate which model to use. One of the most powerful aspects of SharePoint (and, arguably, one of the key reasons why it has been so successful) is the rich API's which provide seemingly endless opportunities for customization. As a middle-tier platform for enterprise web applications SharePoint stands alone in terms of flexibility and extensibility (not to mention the enormous set of features available right out of the box). If you are tasked with creating a web-based line of business application with integrated authentication, data storage, social interaction and collaborative capabilities, you would be hard pressed to find a better framework to build upon. Depending on how deep you need to go into the SharePoint stack, you may find that only the server-side API's will suffice – typical scenarios include public-facing web sites, scheduled task execution via timer jobs, web or enterprise content management functionality, integration with highly-secure backend systems, extensive interface customizations, long running operations on large content-based data sets, email-enabled lists, custom workflow actions, service applications and so on. If your application requirements fall into any of these categories, or you simply need access to a set of API's not covered by the provided remote interfaces (CSOM/REST), then a full trust solution is the correct – and only – option. Design and build it with confidence that, at least for the time being, you're on safe ground in terms of future supportability.
Before you sign off on the final design spec for another big batch of server-side code, though, stop and ask yourself this question: How much of the code actually has to be in SharePoint? After more than a decade writing custom solutions for SharePoint, I've found that less than 20% of the code I've written actually uses the SharePoint API's. The vast majority of it is just standard .NET components and classes. Sure, there have been a few SharePoint-centric solutions that have required deep integration with the dark inner workings of the platform, but by and large that's not the case. Try this – revise your application architecture, separating the core functional elements from the desired integration points and see what you are left with. Based on my experience, I would suggest that in most cases the result would be a blueprint for a provider-hosted app; that is, most of the functionality doesn't require SharePoint at all and the bits that are left can possibly be achieved via the remote API's. Look back on the last few SharePoint solutions you have built and you might be surprised how many of those could run quite happily on IIS somewhere with just a bit of CSOM to facilitate authorization, perform CRUD operations, etc. Now think about how many standalone .NET apps you have in your organization and how they could be benefit from all the SharePoint goodness with minimal code revisions if they were to be repurposed as a provider-hosted app instead of rewritten from the ground up as a traditional SharePoint solution.
The truth behind the marketing hype is that no matter how much the cloud providers want to push you into their service offerings most organizations, especially larger ones, aren't prepared to make such drastic changes so quickly. Even if they want to move wholesale into the public cloud many organizations aren't ready yet and some never will be (finance, defense, healthcare, government, transportation, etc.). Full-featured, on-premise SharePoint is too valuable and too deeply ingrained in many organizations to simply be swapped out for a much more limited feature set in the cloud, no matter how attractive the pricing or outsourced infrastructure may be. For those customers, full trust solutions will continue to be an integral part of the SharePoint story, even if they end up deploying some sort of hybrid architecture (which, in my opinion, is the most likely scenario). This is as it should be – customers who make that kind of investment into a platform should be able to take advantage of its full capabilities (within supportable boundaries, of course). But that doesn't mean full trust is the only option – the app model offers a solid value proposition for certain scenarios and has the added advantage of being portable to the cloud if and when that move happens.
In summary, my advice is to build apps when you can, full trust solutions when you must, and get on board with the current programming trends. It can't hurt and you might be surprised how much you can accomplish with the 2013 app model. Plus, the more SharePoint developers we have building apps, the more we can guide and influence the future direction of the platform. And that's a good thing!
SharePoint is Talking. Are you Listening?
SharePoint Saturday is back in Big D - bigger and better than ever! After a two year hiatus this free community event returns to the Metroplex on November 2, 2013 with a great line up of speakers and in-depth content covering a wide range of topics. From end users to business excecutives, developers and administrators, no matter which SharePoint hat (or hats) you wear in your organization you will find a wealth of real-world information and practical solutions to common problems.
The day starts at 9:00am with a brief keynote followed by break out sessions. Lunch will be provided along with light refreshments throughout the day. Things wrap up around 5:00 with plenty of prizes to give away. But the fun doesn't stop there - be sure to join us afterwards for some "real" social networking at SharePint, where you'll have a chance to mingle with the speakers and ask them whatever SharePoint questions are on your mind.
SharePoint Saturday will be held at the Microsoft Campus in Las Colinas, Texas. This is a free event organized by and for the SharePoint community - space is limited so be sure to register in advance. Visit the offical event website for more information: http://spsevents.org/city/Dallas/Pages/SPSDFW.aspx.
See you there!
SharePoint is Talking. Are you Listening?
SPTechCon 2013 is all wrapped up and it was a great event. Attendance was high, there were lots of enthusiastic sponsors and tons of great content. As a history buff I absolutely love Boston, even though I didn't get to see much of it this time around, which is a shame as the weather was exceptional. The folks at BZ Media do a great job putting on these events – there are lots of conference choices these days but if you haven't been to an SPTechCon you really should put the next one on your calendar.
A big thank you to everyone who attended my sessions. My apologies to the folks who had to stand in the back as all of them were pretty full but hopefully it was worth your time. I still find it hard to believe that we packed out a room at 8:30 in the morning to talk about OAuth!?!
Below are links to archives containing slide decks and code samples (including all the powershell scripts). Please note that you'll need the latest SharePoint developer tools for Visual Studio 2012 in order to build the samples – you can get them using the web platform installer.
Get Some REST - Taking Advantage of the SharePoint 2013 REST API
Rev Your Engines - SharePoint 2013 Performance Enhancements
Who Are You and What Do You Want? Working with OAuth in SharePoint 2013
Pos a comment with any questions regarding the downloads or the sessions themselves. See you at the next one!
SharePoint is Talking. Are you Listening?
We are now accepting speaker submissions for SharePoint Saturday Dallas/Ft. Worth on November 2, 2013. We haven't done this event for a couple of years so there is a lot of pent up demand. It will be a great opportunity to share your thoughts and experiences with other members of the community.
For those not in the Dallas/Ft. Worth area, SharePoint Saturday is a free community-led event so we unfortunately do not have budget for travel and expenses. But we will show you a darn good time while you're in town! We welcome submissions from everyone with something who feels they have something valuable to share - you don't need to be a seasoned presenter to be considered for a speaking slot.
Please use the link below to submit your session topics for consideration. We will follow up via email in the next few weeks if your session is accepted. We're looking forward to a great event!
SharePoint Saturday D/FW Speaker Submissions: http://www.surveymonkey.com/s/H8MK78T
Note: For general information about the event, please visit http://www.spsevents.org/city/Dallas/Pages/SPSDFW.aspx.
SharePoint is Talking. Are you Listening?
Since the introduction of the app model for SharePoint 2013 and SharePoint Online (Office 365) development was announced last year, much has been written on the topic of full-trust solutions versus apps (see Andrew Connell's post and this one from Richard DiZerega). While the larger debate of how new applications should be written for SharePoint going forward is valid and worthy of much more attention that it has been given from non-marketing sources, one of the facets of the discussion that hasn't received much attention is the basic validity of the app model in the enterprise. If an organization is currently considering SharePoint 2013, either online or on-premise, it is important to understand the current capabilities of the model Microsoft is promoting as the future development direction for SharePoint solutions and its present limitations before deciding upon which approach to adopt.
The app marketplace concept is one that has proven to be popular and effective for consumer-focused applications. Small, lightweight applications that sell for a nominal fee to thousands of individual consumers are a great fit for a delivery model designed to accommodate mobile devices. Trouble is, enterprise applications are an entirely different breed - they are rarely small or lightweight, are priced in the thousands of dollars, are typically provided on a site-wide or per-seat license basis, are purchased through a structured acquisition process, and often have a significant learning curve. In other words, they just don't "fit" into a "store".
Take the licensing issue as a prime example. Currently, in order to purchase an app, the customer must authorize it not only on a site-collection by site-collection basis but on a user by user basis as well. There is no ability to assign licenses to any kind of group or set of unnamed users - they have to be assigned to individual named users in each site collection. Think of an enterprise with dozens of web applications, hundreds of site collections and tens of thousands of users - there is no way that the current licensing model will ever be accepted in this scenario. Site admins are simply not going to go through the pain and suffering to make this happen even with automation tools like PowerShell to help out. What happens when a user leaves the company? How does the license get reassigned? And what about archived site collections - how do all those licenses get moved? It's an administrative nightmare and not one that enterprise customers are willing to accept, especially when all the other enterprise application vendors (including Microsoft themselves) are more than happy to provide a license key and volume licenses for "real" software products.
Then there is the payment issue. Assuming the licensing hurdle is overcome (which has about as much chance of happening as the Dallas Cowboys ever making it back to the Super Bowl), how does a vendor listing a product that sells for, say, $150 per user, deliver it via the marketplace? How does a customer with ten thousand users buy that? Just slap down their credit card? Hardly. Worse, what if it's $150 per user per month? There's no model for recurring transactions much less those that sell for umpteen thousands of dollars. That kind of spend requires a purchase order - but who does that go to? Microsoft? The vendor? How are the taxes paid across state or - dare I even say it - international borders? Vendors can't even see who their customer is in the woefully inadequate seller dashboard - how do legal and tax departments deal with a complete lack of customer info? Does Microsoft want to become the go between in that scenario? Not very likely.
It is also common for enterprise apps to have a lot of dependencies and integration points with other applications. The current deployment model provides only for authorization related to permissions. What about configuration parameters for an app that needs to connect to various resources both inside and outside of SharePoint? Most vendors deal with those issues by providing an installer or setup application but the app model doesn't provide any such capabilities. SharePoint has the capability to store configuration data on a farm, web application, site collection or site basis but apps don't have access to any of those repositories. They don't even allow for provisioning of dynamically named artifacts at runtime - the developer must force the user to accept their object names for things like lists and libraries or calls the app makes into the SharePoint site will fail. That's ridiculous - especially in multi-lingual scenarios.
In the cloud, deploying apps is a relatively easy process, as it should be - after all, that is the scenario apps were designed for in the first place. Select an app, authorize it, and off you go. But on-premise app deployment is an entirely different matter. By adopting OAuth as the mechanism for app authorization (made even worse by the absolutely horrible 2.0 implementation of the protocol), Microsoft made it entirely too difficult for apps to be deployed inside the corporate firewall. The need to establish server to server trusts (also known as "High Trust Apps" - see my deployment walkthrough here and related posts here and here) and bind them to individual web applications causes too much friction. Getting an app to run in production is a multi-step process involving SSL, certificates, metadata endpoints, token issuers, identities, realms, and a host of other variables. Why would any developer go through that much trouble when they can simply write a full-trust solution and get access to everything the server object model has to offer?
This leads directly into another major area of concern - the limitations of the client object model. It's all well and good to hype up the app model as the way forward but until it has feature parity with the server object model all that marketing hype is just that - hype. Pretty comparison charts showcasing all the things the client OM can do aren't very helpful when they only focus on the Foundation-level workloads. The truth is that even within this very narrow set of features the client OM only provides access to a portion of the currently available server methods. And it gets worse - what about enterprise content management (ECM)? Publishing and web content management (WCM)? Business intelligence (BI)? Workflow? Taxonomy and metadata? You know - all those killer Enterprise features that make SharePoint the biggest, baddest collaboration platform on the planet? The client OM has very limited capabilities in these areas and getting there will take years of development just to reproduce what we already have in the server OM - talk about running in place and not moving the ball forward. Until an app can do what even the simplest web part or application page can do it's not really an app - it's just an add-on.
Furthermore, the isolation model for apps is confusing, fractured and ill-suited to its task. The concept of app webs as a pseudo site collection that inherits permissions from the host web and attempts to hide or obfuscate basic SharePoint functionality is laughable at best. Users deploy apps to SharePoint sites - they expect those apps to work in the context of that site. Trying to explain to them that, no, in fact the app doesn't really live on that site but some other site they can't navigate to is an exercise in amateur improvisational comedy. Nobody wants to hear such nonsense - if an app deploys a list or page they want that artifact to be on the site where they clicked on the tile in the first place not some weird location that doesn't even have basic navigational elements. And the gyrations that developers have to go through in order to deploy artifacts where users expect and need them to be completely undermines the whole concept of the app model making SharePoint development easier. Those unfamiliar with the SharePoint platform will either give up in frustration or lose so much productivity trying to figure it out that they'll end up regretting ever haven been thrown into the SharePoint mess.
And that, unfortunately, is exactly where we are today. The app model in its present incarnation doesn't make customizing, extending or enhancing the platform any easier on customers, developers or vendors. It just adds more confusion, with a heap of half-baked features and ill-designed integration points. That's not to say the model is wrong or misguided but rather that the implementation falls well short of what is needed to gain widespread adoption in the same way the on-premise development model has. At least in the full-trust solution scenario we now have enough experience to provide best practices and proven strategies for limiting the negative impact of a nearly complete customization framework - apps, much like sandbox solutions before them, are being promoted as a viable alternative but currently have too many restrictions and limitations to come anywhere close.
It is tempting to brush aside these concerns with misdirected arguments that are all about Office 365/SharePoint online and the whole cloud initiative. The discussion here is about adoption of the model in the enterprise and the truth is that SharePoint always has been, and will continue to be, an enterprise application. While small businesses can certainly benefit from the deep and rich feature set that SharePoint brings to the table it is the enterprise customers who have made it into a standalone multi-billion dollar business. And much of the sticking power of the platform has come from the efforts of third-party vendors whose products enhance and extend the platform. In order for the app model to gain any traction it must facilitate the ISV ecosystem or enterprise customers will ignore it at best and abandon it altogether at worst.
Expanding the context of the argument into the area of overall strategy, a cloud-based solution to the collaboration problems of small to medium sized businesses is an important market initiative and Microsoft is quite right to try and exploit a market they have all but ignored for the past few years. But doing so at the expense of enterprise customers, whose spending far outweighs that of smaller customers, is a recipe for disaster. The powers that be should remember that low-cost solutions which are easy to buy are also easy to abandon - all it takes is one major outage or security breach for flocks of customers to switch to another vendor. That's difficult if not impossible to do with large enterprise customers - they will invest in a platform for the long term and stick by a vendor until it becomes infeasible to do so. If some portion of those customers are willing to accept a limited-feature version of the application that runs in the cloud then that's fine but the vendor had better find a way to keep them happy - otherwise the cloud gives them an easy out that they never had before if they become dissatisfied.
A tightly integrated enterprise app story would be a great way to achieve large customer loyalty. Even if they could switch to someone else for core collaboration features the amount of effort invested in app customizations would keep them from jumping ship the first time the winds blow in an unfavorable direction. And if the model can truly be made portable between the cloud and on-premise implementations it would be a real game-changer, allowing enterprise customers to choose which deployment model they want without having to worry about extensibility limitations. At some point the powers that be are going to have to wake up and realize that many large customers are never going to go all in on the public cloud - they may let cloud vendors have bits and pieces of certain non-essential functions but the risk is far too great to allow valuable company data outside of a controlled computing environment. And a hosted solution like Office 365 dedicated isn't going to suit their needs either so long as the vendor continues to impose unrealistic restrictions.
[As an aside, it is amusing how many times the IT industry has gone through this same cycle of central versus distributed resource ownership, each time acting as if the latest swing in one direction or the other is the way everything will be done in the future. A note of caution to those who can't remember that far back - mainframes were the "cloud" to terminal "clients" way back in the 60's and 70's. Nothing has changed much - racks of 1U servers look an awful lot like those big IBM boxes of yesteryear, with thousands of "clients" all connecting over a "web" of discreet endpoints. Everything old is new again - indeed.]
The SharePoint app model could have promise within the enterprise but only with significant changes. The capability, deployment, delivery and licensing issues all have to be resolved before customers with real money to spend will come to the table. I believe it can be done but only by focusing on the core framework and not running in circles around the edges looking for the next shiny object to get the fickle consumer's attention. Take a step back, build it right, and SharePoint can continue to occupy center stage in the collaboration space, regardless of whether it's on premise, online, or both. Failure to do so by simply extending the status quo with incremental improvements will likely lead to disaster. There's too much money at stake - it won't take long before another vendor steps in to do what the current vendor is unwilling or unable to do. And then we'll all be talking about the old days when that SharePoint thing was cool…way back when.
UPDATE: For clarification, this post is not intended as a slam on the app model, SharePoint 2013, Office 365 or the cloud in general. I've been shouting from the rooftops about the app model for over a year and have helped many organizations create a roadmap for development on it. There is no question that this represents a new direction for Microsoft in general and SharePoint in particular and that there are a lot of opportunities for improvement. What I have noticed is that most of the conversation in the community around the model in general has been from a consumer or seller point of view and driven primarily by marketing. My intention is to bring the discussion around the the bread and butter of the SharePoint market - enterprise customers. Adoption of the model by this customer segment is crucial and attention must be given to their needs as opposed to the small business customer or casual consumer. I am hoping that by taking a stand on behalf of a specific customer segment that more attention will be given to this not only in the greater SharePoint community but within Microsoft itself.
SharePoint is Talking. Are you Listening?
SPTechCon in Boston is just around the corner but it's not too late to register. Hit up the registration link and reserve one of the last spots. Boston is a great town and this event is jam-packed with tons of good content. Don't miss out!
I'm presenting three sessions at the conference:
Rev Your Engines: SharePoint 2013 Performance Enhancements
Deploying a SharePoint environment that can scale from several hundred to tens of thousands of users can be a daunting task which requires careful planning and testing. In this session we will explore the basics of SharePoint capacity planning and discuss best practices for the configuration of databases, service applications, web applications, site collections and lists. We will also review ways to avoid common mistakes and highlight tools and techniques administrators can use to monitor SharePoint performance and identify common causes of performance issues.
Get Some REST: Taking Advantage of the SharePoint 2013 REST APIs
The SharePoint 2013 App Model introduces a new programming framework that provides expanded capabilities for remotely hosted sites to interact with Office365 and on-premise environments. A key part of this new model is an expanded and updated set of REST API's. In this session we will explore the new REST capabilities in SharePoint 2013, learn how they are used and discuss best practices for implementation, security and performance.
Who Are You and What Do You Want? Working with OAuth in SharePoint 2013
The new SharePoint 2013 App model extends native SharePoint applications into the cloud, allowing developers to write applications that interact with SharePoint data remotely. With these new capabilities come additional challenges for managing security and user authorization via OAuth. Administrators, IT professionals, and developers should attend this session to familiarize themselves with the core concepts behind OAuth in SharePoint 2013, learn how best to configure and manage OAuth in their environment, and discover how OAuth is used in the SharePoint app model.
: Be sure to attend the OAuth session if you are a Doctor Who
fan - test your knowledge and win some cool prizes!
See you in Beantown!