Showing posts with label SharePoint 2010. Show all posts
Showing posts with label SharePoint 2010. Show all posts

Monday, June 30, 2014

Useful Registry Information on SharePoint Installation

In which architecture SharePoint is installed

Answer: check registry,

32bit:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\InstalledProducts\90120000-110D-0000-0000-0000000FF1CE

64bit:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\InstalledProducts\90120000-110D-0000-1000-0000000FF1CE

In which language SharePoint was installed?

Answer: check registry

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\ServerLanguage\<LCID>

here you should see only one LCID

Which SharePoint language packs were installed?

Answer: check registry

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\InstalledLanguages\<LCID>

here you will see something like this:

LCID - Reg_SZ - {language pack build level}

1033 - Reg_SZ - 12.0.4518.1000

1031 - Reg_SZ - 12.0.4518.1000

...

or

LCID - Reg_SZ - {language pack build level}

1033 - Reg_SZ - 12.0.6219.1000

1031 - Reg_SZ - 12.0.6219.1000

...

Note: It's important to have all language packs on the same build level!

Which server role is installed on each the server?

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS\ServerRole

Value = {Application || WebFrontEnd ||Standalone}

To get an overview about all Microsoft LCIDs you can use this article: Local ID (LCID) chart

Here are my favorites:

Locale description

Short string

Hexadecimal value

Decimal value

English - United States

en-us

0x0409

1033

French - France

fr-fr

0x040C

1036

German - Germany

de-de

0x0407

1031

Spanish - Spain (Traditional)

es-es

0x040A

1034

Italian - Italy

it-it

0x0410

1040

Which Custom Code was installed on the farm?

Answer:

a) Get All WSP-Files from FARM using SharePoint Farm Solution Extractor

b) Check if features were installed without wsp files!

using WssAnalyzeFeatures to get a list of all featureID's inside the farm. Then you need to compare the featureID's with the 12-Hive-Features-folder. Here you should find for each featureID the feature binaries.

c) In case you do not have the feature binary any more it's important to remove the feature completely from SharePoint using WssRemoveFeatureFromSite.

Thursday, January 6, 2011

Creating a Feature with Custom Action to Add Site Manager Menu in Site Actions Menu

Overview
You can add a custom menu item to the default Site Actions menu in Microsoft Windows SharePoint Services by creating a Feature with a CustomAction element. In this way, you can add custom commands to the default SharePoint user interface. These commands are available to users as they move between pages on a SharePoint site. When you create a Site Actions menu item, you can configure it to redirect the user to any URL. For example, you can redirect the user to another Web site. You can also redirect users to a custom application page that allows them either to see a custom display of data, or to perform custom operations on the content within the current site.


Code It

1. Create a new Project in VS 2010 and under SharePoint (left) select Empty Project
2. Now enter the url of your SharePoint site for debugging and select deploy as a farm solution.
3. Now, once you have the project open, right click on the Feature folder and Add a new feature.
4. SharePoint automatically adds a feature and names it as Feature1. You can however change the feature name to something like CustomActionFetaure.
5. With this you will have a feature designer opened in front of you set the Title description and scope of the feature.
6. Now right click on the Project and add a new Item. In the Add New Item dialog, select Empty Element to create a blank element file.
7. Add the below Code to the element.xml file
8. Build the Project. Open the feature.xml file and verify that if contains the reference to the element.xml file.
9. Now Deploy the wsp and activate the feature in your site.

Read It

When you create a CustomAction element, you must add an inner UrlAction element that contains a Url attribute. When you redirect the user to an application page, such as ApplicationPage1.aspx, you must consider whether you want the application page to run inside the context of the current site or the current site collection. In the following example, the dynamic token ~site is added to the beginning of the URL. When Windows SharePoint Services parses this CustomAction element and creates the menu item, it replaces ~site with the actual URL of the current site.
"~site/_layouts/sitemanager.aspx"
The key to security trimming your custom action is the Rights attribute. This attribute allows you to specify SharePoint permissions that the user must have for the action to be visible. This can be a comma delimited list. For example:
Rights="ViewListItems,ManageAlerts"
When more than one value is specified, the set of rights are treated with an AND. This means the user must have all of the specified rights for it to be visible. Here is a list of the valid Microsoft.SharePoint.SPBasePermissions you could use:
Also, When you create the element for a custom menu item in the Site Actions menu, you have the option to configure it so that it is shown only to users who have administrative permissions. Note in the following example the addition of a new attribute named RequireSiteAdministrator.
RequireSiteAdministrator="TRUE"
When you add the RequireSiteAdministrator attribute, Windows SharePoint Services does not show the menu item to users who do not have administrative permissions. For a CustomAction element in a Feature that is scoped at the site-collection level, the menu item appears only for the site collection owner or administrator. For a CustomAction element in a Feature that is scoped at the site level, the menu item appears only to those who have administrative permissions within the current site.

Finally

Monday, September 20, 2010

iisapp equivalent in IIS7 (Related to Windows 2008 or above)

When working with IIS 6.0 it was pretty handy to use the iisapp VbScript to find out which w3wp worker process relates to which Application Pool. In IIS7, this script doesn’t work anymore. There is a replacement though. You can add the command below to a batch file and just call it:



%windir%\system32\inetsrv\appcmd.exe list wp