This document provides 10 steps and common mistakes to avoid for successful deployment of SharePoint. It outlines key considerations such as separating development, test, and production environments; avoiding custom site definitions when possible; not modifying databases; having separate environments for different uses; and understanding the importance of testing and following best practices for upgrades. It also advertises upcoming products and services from Quest to help with SharePoint deployment, development, and migrations.
9. Project Management office needs Project Portfolio, Finance needs Reporting Server, PowerPivot and Access Services, CIO needs PerformancePoint, Fast Search for our Intranet, then there’s Internet, oh and our Claims based extranet…What’s wrong? They are all MS Products… Cual es el problema, todos son productos de Microsoft…
10. Live by the K.I.S.S. PrincipleKeep it Simple,Stupid Vive por el principio M.S. Mantenlo Simple
11. Our developers don’t like the way SharePoint looks and works, so we’re going to use Site Definitions to get it to look and work the way we want it to… A nuestros desarrolladores no les gusta como se ve y trabaja SharePoint, por lo que vamos a usar SiteDefinitions para que se vea y trabaje como queremos …
12. There aren’t enough triggers for what we need in the databases, we can always remove them later. Come on a little table can easily be removed later… No hay suficientes triggers para lo que necesitamos en la base de datos, siempre los podemos quitar después. Una pequeña tabla la podemos quitar después…
13. SharePoint has approvals, it’s so much easier when we all work together in the same environment… --- No need for a Test environment… Share Point tiene aprobaciones, es mucho mas fácil que todos trabajemos en el mismo ambiente. -----No se necesita hacer una prueba de ambiente ----
15. We want our departments to “Share” so we use the same portal for our collaboration, engineering, projects and our intranet portal, we just use different webs in one Site Collection.
16. Pyramid of SharePoint Information Permanent Central Portal Enterprise Search Enterprise Browse Corporate Business Taxonomy With Divisional Stakeholders Central Portal Permanent Division Portals Business Process Division News, Scorecards Group Reporting Semi Structured Group, Team, Project Sites and Workspaces Ad Hoc Self Service w/ Life Cycle Management Per User Blogs, bios, Social
17. We believe in SharePoint so we’re shutting down our Public Folders, File Shares and getting rid of attachments in Email. Nosotros creemos en Share Point por lo que vamos a cerrar nuestros fólderes públicos , fólderes compartidos ,y nos desarenos de los attachments en los e-mails.
18. “We don’t plan to use My Sites or Social computing in SharePoint 2010 because we don’t want our employees to waste time…” No planeamos usar My Sites o Social computing en SharePoint 2010, por que no queremos que nuestros empleados pierdan el tiempo…
21. Sandbox solutions are too hard and JQuerydoesn’t give us anything Las soluciones Sandbox son muy duras y las soluciones Jquery no nos dan nada..
22. We are using InPlace Upgrade because we don’t want to lose anything. Nosotros usamos InPlaceUpgrade por que no queremos perder nada.
23. 10 Major Mistakes I don’t know what to do, so I’ll turn it all on… Turn the lights on for the Services you need, turn on more as you need them. Project Management Office needs Project Server, Finance needs Reporting Server, PowerPivot and Access Services, CIO needs PerformancePoint, Enterprise Search for our Intranet, then there’s our Internet Site, oh and our Claims based extranet… we can easily do this in one box… Separate Dev/Test/Prod, but also separate unlike environments to Keep it Simple. Our developers don’t like the way SharePoint looks or how it works, so we’re going to use custom Site Definitions to get it to look the way we want it to… Avoid Create Site Defs if at all possible… Use Solutions Features and Master Pages!
24. 10 Major Mistakes Continued… There aren’t enough triggers for what we need in the databases, we can always remove them later… Mucking with the database will result in NO SUPPORT from MS, and failed upgrade. Talk about CO$T! SharePoint has approvals, it’s so much easier when we all work together in the same environment… Dev environments are required for any Dev work, Test are mandatory for any SharePoint Environment for testing service packs. We want our departments to “Share” so we use the same portal for our collaboration, engineering and our intranet publishing, we just use different webs in one site collection. There are many reasons to split out your data 1) Growth 2) Quota 3) App Dev 4) Manageability 5) Not all departments have the same requirements
25. 10 Major Mistakes Continued. We believe in SharePoint so we’re shutting down our Public Folders, File Shares and getting rid of attachments in Email. What’s wrong with that? Garbage in Garbage out. Never plan to dump your shares into SharePoint. We don’t plan to use My Sites or Social computing in SharePoint 2010 because we don’t want our employees to waste time. Social computing helps overcome silos. Social encourages cross group collab. Sandbox solutions are too hard and Jquery doesn’t really get us anywhere. Client solutions free up IT time and provide control. We are using InPlace Upgrade because we don’t want to lose anything. Study. Database Attach or Hybrid is a better approach.
26. SharePoint 2010: Best Practices for Upgrading & Migrating Collection of blogs on Upgrade & Migration Guidance from Joel Oleson, Comics from Dan Lewis, Plus… Anders Rask Upgrading Custom Features & Solutions Reserve your copy now in Amazon Bit.ly/spupg Available in Print in August Available now in ebook in Rough Cuts on Safari http://oreil.ly/SpUpgrade