Building Multilingual Solutions by Using SharePoint Products and Technologies

Hot to use Microsoft® Office SharePoint® Server 2007 in scenarios where content is managed across different languages. It details most of the functionality provided by Office SharePoint Server 2007 and suggests how to use it to manage multilingual scenarios. It also provides examples for creating custom Web Parts by using Microsoft Visual Studio® 2005 and how to configure and manage them by using Microsoft Office SharePoint Designer 2007, the next generation of Web designer tools specifically designed for SharePoint sites. Microsoft Windows® SharePoint Services 3.0 features and functionality, and how they add value to the end-user experience, are also described.
http://technet.microsoft.com/en-us/library/cc262942.aspx

Some of the key areas should know as a MOSS admin

I am giving some of the key points about the daily activities of a MOSS dev.
Reusing Sites
•Save site as template
•Works for all sites except publishing sites
•Default template limit 10 MB
▫Change via command line
▫Change to max of 500 MB
Stsadm.exe –o setproperty–pnmax-template-document-size –pv524288000
•Does not save security

Site Templates Usage
•Save Site as template
•Saved to Site Template Gallery
▫1 per Site Collection
Use Template Globally
•Deploy via command line
•Add Template
Stsadm–o addttemplate–filename YourFile.stp –title YourTitle–description YourDesc
•Delete Template
Stsadm–o deletetemplate–title YourTitle
•List Templates
Stsadm–o enumtemplates
•After running Add/Delete IISResetrequired
List Templates
•No option for deploying globally
Feature deactivation
▫Removes functionality
▫Does not remove data created by feature
Setting trust level
•Options
▫WSS_Minimal(default)
▫WSS_Medium
▫Full (built in .NET Policy)
Code Access Security in SharePoint 2007 for Administrators
SharePoint Web Parts run with a Trust Level which is set in the Web.Config file for the entire Web Application allowing not just one Web Part, but all Web Parts to run with that trust.
The default trust level that the Web Application runs with is WSS_Minimal. Developers will normally request that this is set to WSS_Medium or Full which are the only other configurations possible unless the developer creates a custom configuration file.
Code Access Security – The Architecture
In the Web.Config file for the web application you will see two Trust Level Elements in the Security Policy Element pointing to the two configuration files stored in 12\CONFIG (localdrive:\program files\common files\microsoft shared\web server extensions\12).
Each configuration file configures a number of classes by setting its properties. The classes are illustrated below.

The default Trust is WSS_Minimal which allows most code to run but would block your code from accessing SQL, The SharePoint Object Model, Environment Variables such as Machine Name and DNS etc. To allow these permission you would need to up the trust level to WSS_Medium, Full or to a Custom Policy. However, increasing the Trust Level for the Web Application would allow all Web Parts within that Web Application to run with more permissions. Best practice would be to create a custom policy and listing your web part in the file to run with the permissions it needs.
To create a new set of permissions you need to create a new file such as Custom_WSS_Medium.config and then make SharePoint aware of the file by pointing to it in the Web.Config for the Web Application. You can merge the settings in WSS_Minimal and WSS_Medium in your new Custom File to create your own permission set. It is advised not to change the original files as Microsoft may alter these files during the application of a Service Pack.

Each custom Web Part should be Strongly Named by the Developer which provides the DLL file for the Web Part with a Public Key. You can extract the Public Key using the SN tool provided by Visual Studio.NET: sn –Tp filename.dll
This will return the Public Key BLOB and the Public Key Token for the dll. Normally this would be a developer role as it requires Visual Studio.NET.

The Public Key Token is used in the Safe Controls entry in the Web.Config for the Web Part (Assembly) to register it as a Safe Control within the Web Application. The Public Key can also be used in the custom Trust Level Configuration File to give one particular Web Part or a group of Web Parts Full Trust whilst still leaving the Trust Level set to a minimal set of permissions.
To list a Web Part with Full Permissions within your Web Application whilst still retaining a WSS_Minimal permission set for all other Web Parts follow these steps:
1. Make a copy of the WSS_Minimal.Config file from the 12\Config folder and paste it into the same folder renaming it to Custom_WSS_Minimal.Config.
2. Edit the Custom_WSS_Minimal.Config file with an XML editor such as Visual Studio.NET or NotePad.
3. Obtain the Public Key Token and Public Key Blob for the Web Part assembly that you want to deploy using the following command: sn –Tp filename.dll.
4. Create a new entry in your Custom_WSS_Minimal.Config file for your Web Part:
class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust"
Name="My custom Strong name"
Description="This code group grants code signed with the “My Custom
Strong Name” strong name full trust.">
PublicKeyBlob="00240000048000009400000006020000002400005253413100040000010001009BC5B83BBD16C6ABB44BAB156CF9C55D1D67078CE98CE7B423C72EE91647BD73241BFC700192ED32481CA7CF06C205BD4C7BEDA3D4FA5ED5689AA23BC1C2118EBFA6018238AD5B4DA420FB335E6BECA9EDE5E3F53C4BFFF266411445AE7B1DDD14FB0F01C075589770EABD4B1D1A70F731C098F22EDE9838CC9783C73451B5"/>

5. Create a new TrustLevel element for your config file in the Web.Config called Custom_WSS_Minimal that points to your custom file in the 12\config folder.
6. Set the Trust Level of the Web.Config to Custom_WSS_Minimal
7. Recycle the Application Pool or run IISReset
8. Deploy & Test your Web Part.