January 2008 - Posts

• Best Practices of MOSS 2007 Hosting(Upgrade)

  As we know, there are three main ways to perform an upgrade to Office SharePoint Server 2007: In-place upgrade Gradual upgrade Database attach I used each of the three strategies in different scenarios. However, we overwhelmingly favored gradual upgrade and database attach due to the quantities of sites and data involved, in addition to the large number of users affected.So, I would like to recommend the following best practices for deployment of an Office SharePoint Server 2007 solution within an enterprise. In some cases, deploying the solution without following these suggestions is possible, but this may result in unnecessary expense or effort. Perform a thorough audit of all products and platforms that the upgrade may affect, including Windows Server, SQL Server, IIS, Windows SharePoint Services, and prior versions of SharePoint Products and Technologies, in addition to portals, sites, and content. Make sure that level settings are consistent across the environment to be upgraded. Identify and install missing language packs. Doing so during the upgrade itself is inefficient and can cause problems. Schedule and analyze prescans by using the prescan tool (Prescan.exe) at least two days before each upgrade. Upgrades can fail for a variety of reasons. Have a contingency plan in place in case minor or major roadblocks occur. Determine the priority of exceptions and to what degree they will be allowed to affect the schedule. Communicate this information to affected users. Schedule, perform, and confirm backups before performing upgrades. Ensure that backups and upgrades are not scheduled to run at the same time, because this will cause upgrade failure. In performing a database attach, the number of sites is the most important factor in how long the upgrade will take. If many sites exist on a farm, schedule upgrades based on the number of sites. If there are fewer sites (as may be the case with team and portal sites), schedule them based on the quantity of data. Define the upgrade process thoroughly before sending communications about the schedule and process. Not doing so will confuse end users and may encourage them to think the schedule is negotiable. Perform a dry run whenever feasible. Identifying and fixing problems beforehand will increase the likelihood of maintaining the schedule after the upgrade begins. Do not avoid testing because of limited hardware resources. Use virtual machines for testing if excess hardware capacity is not available. Data requirements usually grow during an upgrade; exceeding the capacity of a database will cause the upgrade to fail. Increase the target databases to appropriate sizes before the upgrade process and set databases, temporary databases, and log files to autogrow. Watch for upgrade problems caused by full-text search. Moving the SQL Server database to a different server or disabling full-text search on the SQL Server computer can mitigate the impact. Do not finalize the upgrade until you are sure the upgrade is finished. Finalizing the upgrade removes the connection to the previous version and deletes any temporary data, and it is irreversible.   Hope this helps! Posted Jan 06 2008, 12:20 AM by LovedJohnySmith with 1 comment(s) Filed under: Best Practice

• Power of SharePoint Team Collaboration

  I got a chance to work with one of the top 5 fortune company for re-design of their intranet portal. I'd like to share this project experiences and power of sharepoint team collaboration with you folks - We worked in conjunction with one of the top 5 fortune company's IT to re-design their intranet portal, the company's enterprise intranet portal. The design was based on well-researched employee needs and business goals and implemented using the latest release of SharePoint Portal Server 2007. The key areas of improvement in their intranet portal included development of new capabilities for: Improve the ability to find and retrieve the "right" information Information workers were confused by too many choices for storing content Teams needed common collaborative processes to work effectively together. Supporting multiple storage and collaboration platforms was expensive and complex for IT. Employees who used previous versions of their Web found it difficult to find the right amount of current, relevant, and authoritative information in the diverse and fast changing environment of their intranet. Four key problems related to finding the right information: It took too long to find the "right" information. This was often described in terms of taking too many mouse clicks to find useful information or not being able to find the right information after spending considerable effort searching and navigating the intranet. It was hard to locate information and knowledge that was relevant in the context of the immediate task for an employee to complete his or her work. For example, search results often included too much unrelated information to be useful. It was difficult for an employee to know when they could rely on information they found on the intranet. It was also difficult to ascertain whether that information was timely, accurate and complete. Employees found it difficult to know the best keyword choices to use for searching because of the large number of acronyms, technical terms, project code names and product names in regular use at their organization. One of the best solution to find the right information(i.e., reduce the number of mouse clicks) is provide a custom search based on their custom content type(which is inherited from **Document** contenttype) Ex: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1881103&SiteID=17 Posted Jan 06 2008, 12:02 AM by LovedJohnySmith with 1 comment(s) Filed under: SharePoint