Monday, October 20, 2014

No Mysite link in MOSS 2007 page

To enable the Mysite link follow the below steps :

  • Go to the Central Administration Web Page
  • Click on the link for Shared Services Administration
    • If you have more than one Shared Service Provider (SSP), select the one that is running the "My Sites" functionality
    • Under "User Profiles and My Sites", click "Personalization Services Permissions"
    • Click Add Users/groups
    • Add the name of the user who was not able to see the "Mysite" link and provided them with "Personal site" and "Personal feature " permission .

Thursday, October 16, 2014

Steps to run SYDI to check System configuration .

The script generates machine data in word format which will help us to get an insight into the machine configuration .


Step 1 : Download the SYDI tool from http://sydiproject.com/) into the machine where you want to check configuration .
 

Step 2 :

If MS word is installed into the machine whose configuration needs to be checked .

·         Open the command prompt and navigate to the path where you have copied the attached file .
·         Type the command : cscript.exe sydi-server.vbs [enter]
·         A message box appears and asks you which host you want to target, the default is localhost. You can select another host if you have administrative access on that machine. Though for now, just press enter.
·         In the command prompt window you will now see that SYDI starts to gather information about your machine. Soon a Word document is created and SYDI writes the information gathered into the document.
If MS word is installed into the machine whose configuration needs to be checked . Eg : Our PPFA front end server where MS office is not installed .

·         Open the command prompt and navigate to the path where you have copied the attached file .
·         Type the command : cscript.exe sydi-server.vbs -oServer1.xml -ex –sh [enter]

·         A message box appears and asks you which host you want to target, the default is localhost. You can select another host if you have administrative access on that machine. Though for now, just press enter.
·         In the command prompt window you will now see that SYDI starts to gather information about your machine. An XM file will be generated in the path under which the command is run with the name “Sever1” .
·         Copy the XML file generated to a system where MS is installed (may be your local desktop) .
·         Now in the new machine where you have copied the XML file also copy the attached scripts .
·         Open the command prompt and navigate to the path where you have copied the attached file .
·         Type the command : cscript.exe ss-xml2word.vbs -xServer1.xml -llang_english.xml [enter]

·         In the command prompt window you will now see that SYDI starts to gather information from “Server 1” xml file and soon a Word document is created and SYDI writes the information gathered into the document.

Friday, June 27, 2014

SharePoint 2007 to 2010 Migration using DB attach method

Below is a useful link SharePoint 2007 to 2010 Migration using DB attach method.
http://www.orcsweb.com/blog/cory-granata/sharepoint2k7-to-2k10-migration-using-db-attach-method/

Monday, June 23, 2014

SharePoint Storage Issues

Most SharePoint storage concerns are about size calculations. You will find some information below on how disk space is occupied by the site and how its content is calculated.  

First of all, adding a document to a library consumes much more space than you might think. For every document, there is also the metadata and index data that goes with it. If a document is stored in a standard folder and has a standard set of properties associated with it, the document will consume about 12 KB for metadata, plus about 30% of the total document size for indexing. Therefore, if a document is 100 KB in size, you can expect to consume 100 KB for the document, 12 KB for the metadata, and 33.3 KB for the index. Your 100 KB document just consumed 145 KB.

Other common reasons for unexpected site growth are the use of versioning in Document Libraries or an uncontrolled Second Stage Recycle Bin.

Problem #1: Versioning in Document Libraries

Versioning creates a new copy of the document every time the document has been checked out. Therefore, to determine how much space a document in an enhanced folder is consuming, take the number of versions plus one and multiply it by the document size plus the index size, plus the metadata size. This means that if there were four versions of our 100 KB sample document, the document would be consuming 725 KB (four versions plus 1, multiplied by the 100 KB document size, plus 33.3 KB for the index size plus 12 KB of metadata).

Solution: To control versioning settings, open the library and navigate to Settings > Document Library Settings. Then click  Versioning Settings. To learn about versioning, refer to Help for SharePoint on the Microsoft site: http://office.microsoft.com/en-us/sharepointtechnology/HA100215761033.aspx
 

Problem #2: Site Collection Recycle Bin (or Second Stage Recycle Bin)

Whenever the end user deletes data from the site, it goes to the End User Recycle Bin. Items in the Recycle Bin remain there until the end user decides to permanently delete or restore them, or until the items are permanently deleted after the retention period of 30 days. To view items deleted from the site, a user can click the Recycle Bin link in the Quick Launch pane on the left. Users will see only their own files that have been deleted from the site. Even the site Administrator will see only his or her own deleted files in the first-level Recycle Bin.

Solution: If the file is deleted from the "user" Recycle Bin, it is sent to the Site Collection Recycle Bin, where an administrator can restore it or delete it permanently. The Second Stage Recycle Bin can be managed only by a SharePoint Administrator (a user with an email address that you specified as administrator during SharePoint installation).
To view the content of the Site Collection Recycle Bin:
1.      Log in with site administrator credentials.
2.      Navigate to Site Actions > Site Settings.
3.      Under Site Collection Administration, click the Recycle Bin link. 
This opens the Site Collection Recycle Bin, which has two links in the navigation pane on the left:

Problem #3: Unstructured data takeover.

The primary document types stored in SharePoint are PDFs, Microsoft Word and PowerPoint files, and large Excel spreadsheets. These documents are usually well over a megabyte.
SharePoint saves all file contents in SQL Server as unstructured data, otherwise known as Binary Large Objects (BLOBs). Having many BLOBs in SQL Server causes several issues. Not only do they take up lots of storage space, they also use server resources.
Because a BLOB is unstructured data, any time a user accesses a file in SharePoint, the BLOB has to be reassembled before it can be delivered back to the user – taking extra processing power and time.
Solution: Move BLOBs out of SQL Server and into a secondary storage location – specifically, a higher density storage array that is reasonably fast, like a file share or network attached storage (NAS).

Problem #4: An avalanche of large media.

Organizations today use a variety of large files such as videos, images, and PowerPoint presentations, but storing them in SharePoint can lead to performance issues because SQL Server isn't optimized to house them.
Media files, especially, cause issues for users because they are so large and need to be retrieved fairly quickly. For example, a video file may have to stream at a certain rate, and applications won't return control until the file is fully loaded. As more of this type of content is stored in SharePoint, it amplifies the likelihood that users will experience browser timeout, slow Web server performance, and upload and recall failures.
Solution: For organizations that make SharePoint “the place” for all content large and small, use third-party tools specifically designed to facilitate the externalization of large media storage and organization. This will encourage user adoption and still allow you to maintain the performance that users demand.

Problem #5: Old and unused files hogging valuable SQL Server storage.

As data ages, it usually loses its value and usefulness, so it’s not uncommon for the majority of SharePoint content to go completely unused for long periods of time. In fact, more than 60 to 80 percent of content in SharePoint is either unused or used only sparingly in its lifespan. Many organizations waste space by applying the same storage treatment for this old, unused data as they do for new, active content, quickly degrading both SQL Server and SharePoint performance.
Solution: Move less active and relevant SharePoint data to less expensive storage, while still keeping it available to end users via SharePoint. In the interface, it helps to move these older files to different parts of the information architecture, to minimize navigational and search clutter. Similarly, we can “unclutter” the storage back end.
A third-party tool that provides tiered storage will enable you to easily move each piece of SharePoint data through its life cycle to various repositories, such as direct attached storage, a file share, or even the cloud. With tiered storage, you can keep your most active and relevant data close at hand, while moving the rest to less expensive and possibly slower storage, based on the particular needs of your data set.
Problem #6: Lack of scalability.
As SharePoint content grows, its supporting hardware can become underpowered if growth rates weren't accurately forecasted. Organizations unable to invest in new hardware need to find alternatives that enable them to use best practices and keep SharePoint performance optimal. Microsoft guidance suggests limiting content databases to 200GB maximum unless disk subsystems are tuned for high input/output performance. In addition, huge content databases are cumbersome for backup and restore operations.
Solution: Offload BLOBs to the file system – thus reducing the size of the content database. Again, tiered storage will give you maximum flexibility, so as SharePoint data grows, you can direct it to the proper storage location, either for pure long-term storage or zippy immediate use.
It also lets you spread the storage load across a wider pool of storage devices. This approach keeps SharePoint performance high and preserves your investment in existing hardware by prolonging its useful life in lieu of buying expensive hardware. It’s simpler to invest in optimizing a smaller SQL Server storage core than a full multi-terabyte storage footprint, including archives.

Problem #7: Not leveraging Microsoft’s data externalization features.

Microsoft’s recommended externalization options are Remote BLOB Storage (RBS), a SQL Server API that enables SharePoint 2010 to store BLOBs in locations outside the content databases, and External BLOB Storage (EBS), a SharePoint API introduced in SharePoint 2007 SP1 and continued in SharePoint 2010.
Many organizations haven't yet explored these externalization capabilities, however, and are missing out on significant storage and related performance benefits. However, native EBS and RBS require frequent T-SQL command-line administration, and lack flexibility.
Solution: Use a third-party tool that works with Microsoft’s supported APIs, RBS, and EBS, and gives administrators an intuitive interface through SharePoint’s native Central Administration to set the scope, rules and location for data externalization.
In each of these five problem areas, you can see that offloading the SharePoint data to more efficient external storage is clearly the answer. Microsoft’s native options, EBS and RBS, only add to the complexity of managing SharePoint storage, however, so the best option to improve SharePoint performance and reduce costs is to select a third-party tool that integrates cleanly into SharePoint’s Central Administration. This would enable administrators to take advantage of EBS and RBS, choosing the data they want to externalize by setting the scope and rules for externalization and selecting where they want the data to be stored.
If you have any difficulties in understanding the above, please do let me know.
- See more at: http://sharepointknowledgebase.blogspot.in/2012/11/sharepoint-storage-problems-moss-2007.html#.U6iWx_mSxic

Difference between Read and View only permission .

An user having Read permission can able to search and find this document and view it either in Office Web App on the server (in the browser), or in Office client on his computer..

An user having View only permission can browse to the document library and see the document, however he cannot open the document in Office Word client on his computer. Also he will not able to find it using search. Furthermore, if he types the URL of the document in the browser address bar (http://SharepointSite/doclib/sales.docx), he receives an Access Denied error. 

Default permission levels in SharePoint 2010


PERMISSION LEVELDESCRIPTION
Full ControlThis permission level contains all permissions. By default, the Site name Owners group has Full Control. This permission level cannot be customized or deleted.
DesignCan create lists and document libraries, edit pages and apply themes, borders, and style sheets in the Web site. Not assigned to any group by default An administrator must assign this permission level explicitly..
ContributeCan add, edit, and delete items in existing lists and document libraries. By default, the Site name Members group has Contribute permissions..
ReadRead-only access to the Web site. Users and groups that have this permission level can view items and pages, open items, and documents. By default, the Site name Visitors group has Read permission..
Limited Access
By design, the Limited Access permission should be combined with fine-grained permissions. You can use this permission to give users access to a specific list, document library, item, or document, without giving them access to the whole site. However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
Note   You cannot assign this permission level to users or security groups. Instead, the system automatically assigns this permission level to users and security groups when you grant them access to an object on your site that requires that they have access to a higher level object on which they do not have permissions. For example, if you grant users access to an item in a list and they do not have access to the list itself, the system automatically grants them Limited Access on the list. If the user also requires access to the site, the system automatically grants Limited Access to the site..
Manage HierarchyCan create sites and edit pages, list items, and documents. by default, the Hierarchy Managers group has Manage Hierarchy permissions..
Records Center Web Services SubmittersCan submit content to the named site by using Web Services. By default, the Records Center Web Services Submitters group has this permission..
ApproveCan edit and approve pages, list items, and documents. By default, the Approvers group has this permission..
Restricted ReadCan view pages and documents, but cannot view historical versions or user permissions.

Wednesday, June 18, 2014

Site collection backup/restore vs. site export/import

Site collection backup

PowerShell command to backup a site collection
 
Backup-SPSite -Identity "site collection url" -Path "backup file path"
More information for Backup-SPSite: http://technet.microsoft.com/en-us/library/ff607901.aspx

Site collection restore

PowerShell command to restore a site collection
1
Restore-SPSite -Identity "site collection url" -Path "backup file path"
More information for Restore-SPSite: http://technet.microsoft.com/en-us/library/ff607788.aspx

Restore results:

The results are the same when restoring on the same location or another location, in the same web application or another web application.
Results:
-          The restored site collection has new site ID (GUID).
-          All items versions and workflows are restored successfully.
-          Audit events are lost. This happens because of the new site ID (GUID). This can be fixed by updating Audit table in the content database. If the site collection is restored in the same location or another location that uses the same content database then rows in Audit table should be updated by writing the new Site ID in the rows that have the old Site ID. If the restore is done on another location that uses another content database then new rows must be created in the Audit table in the new content database by reading the old audit events from the Audit table in the old content database.

Site Export

PowerShell command to export SPWeb:
1
Export-SPWeb [-Identity] "site url or GUID" -Path "backup file path"
Important: Export-SPWeb does not export the running workflows.

Site import

Powershell command to import SPWeb:
1
Import-SPWeb [-Identity] "site url or GUID" -Path "backup file path"

Import in the same location

If there are event receivers running custom code in the lists it’s recommended to remove all of them before import to avoid any failure caused by the event receiver logic. Depending on the logic of the event receivers import may completely fail or the imported web may have wrong items version history and other problems. After import event receivers can be added back. For removing/adding event receivers with PowerShell check one of my older posts Add, Modify or Delete List Event Receivers with PowerShell

Import results:

-          Import operation does not import the workflows (as expected, because they don’t get exported with Export-SPWeb).
-          Import does not affect the currently running workflows but import of the document versions fails for those documents with running workflow.
-          Versions are correctly imported only for document with no workflows in running state when importing.
-          Audit events are not affected by the import, so all events are retained including those registered between export and import

Import in another sub site

The following must be done before importing the exported site:
-          Create new site using the same template and same language as the exported site
-          As explained above, removing event receiver is strongly recommended

Import results:

-          All running workflows are lost
-          All custom site properties and custom item properties are lost (properties in SPWeb.Properties and SPItem.Properties hashtables)
-          All workflow associations are lost
-          Document versions are imported successfully
-          Audit events are lost
-          Workflow tasks are lost

Conclusion:

Database attach of a backed up content database is superior for custom SharePoint solutions that contain custom workflows, custom web and item properties, custom event receivers, version history etc. To avoid big content database and long backup times its better the custom solutions to be installed in a site collection that has its own content database instead of sharing one content database with other site collections. That way backup/restore space and time will stay in normal and manageable boundaries. In that case you can stick to database backup as the best backup/restore plan for highly customized and big SharePoint solution.
Site collection backup/restore is better than SPWeb export/import but not as trouble free as database backup/restore plan. The problems are caused by the new Site ID (GUID) generated. That causes lose of audit events, or more precisely additional work to correct the Audit table after the restore.
Site export/import is almost useless for custom solutions that contain custom workflows, event receivers, custom web and item properties, custom event receivers, version history etc. It has problems even if it’s used for simple sites that use only SharePoint out of the box functionality if it has lists with workflows and versioning enabled.