Is the Ignite Conference too big?
Sure, there’s benefit by combining several different disciplines into one large conference, but there’s a big downside – especially for smaller support organizations.
You can’t have your support people at a conference and minding the store simultaneously!
If you’ve got your messaging and SharePoint and SQL and… personnel at the conference, how deep is your bench if you run into operational issues?
What about timing with releases, patching, and such for the organization that you support?
And what if the organization (consider outsourced support) has a contingent at the conference, too?
Chicago was a logistical nightmare. A technical conference must be tightly confined for attendees to mix and match without having to grab a cab to attend a desired session.
Maybe Atlanta will be the last experiment at such large convergence. We shall see!
What do you think?
Liam Cleary shares some significant changes we need to be aware of when planning migrations to SharePoint 2016:
Click here for SharePoint 2016 Preview download!
Check out Jeremy Thake’s cheat sheet with new names for the confusing SharePoint and Office “apps.”
Sophisticated solutions developed by ISVs are in a different league than a hobby project app available from the Office Store.
No question, this created problems justifying a few hundred grand for a year-long effort when the CIO sees the plethora of ‘free’ and low-cost apps in the Office Store.
Read Jeremy’s full post for more insight and community comments.
Here’s the cheat sheet if you’re in a rush:
|Apps for SharePoint (old)
||SharePoint Add-ins (new)
|SharePoint App Model
||SharePoint Add-in Model
|Apps for Office
|Office App Model
||Office Add-in Model
If you overbooked and missed a session, or that guy behind you with the post-nasal drip drowned out the speaker, here’s your chance to catch up!
PLUS! Vlad Catrinescu published a script to download and neatly organize the videos and PowerPoint decks from the conference. Thanks, Vlad.
Are you developing for SharePoint in a commercial organization? Eager to get coding before a well-thought-out development environment is planned and stood up?
Cool your jets! Avoid the temptation to get started early and begin creating solutions in a Stand-alone SharePoint installation!
DO NOT develop in a Stand-alone SharePoint environment if you’re doing serious work!
Wait for your project team to formalize the environmental architecture and provision real farms in which you will do development, even if a farm consists of a single SharePoint server and separate SQL instance.
I have delivered the bad news to a development team up against a tight deadline that their performance problems and some system errors are the result of the Stand-alone deployment.
For starters, if you have Visual Studio, SharePoint (with a boatload of Services enabled), SQL Express, troubleshooting tools, and the Kitchen Sink running in what is likely a 2-core, 4 GB virtual instance on an over-subscribed virtual host, you are already asking for Big Trouble.
Don’t paint yourself into a corner with a Stand-alone deployment!
Most likely you are unaware (as was I until I researched a bunch of errors) that a Stand-alone deployment will not support all ‘normal’ SharePoint functionality. If you look at the Services status page, you won’t see a clue that anything is amiss!
See these caveats from the authoritative TechNet article on single-server SharePoint 2013 installations:
Consider the following restrictions of this method of installation: