Thursday, December 27, 2007
Tuesday, December 25, 2007
Visual Studio VS SharePoint Designer
A few basic differences between these two amazing development tools
Visual Studio ==> VS
SharePoint Designer ==> SPD
Visual Studio ==> VS
SharePoint Designer ==> SPD
- Code Behind
Yes (VS)
No (SPD) - Development Model
Graphical Designer (VS)
Wizard Based (SPD) - Supported WF Hosts
WSS/MOSS/Others (VS)
WSS/MOSS (SPD) - Type of WF Supported
Sequential & State Machine (VS)
Sequential (SPD) - Activities
Built-in, Use & Dev Custom (VS)
Built-In & Use Custom (SPD) - Form Technology
Design forms in any technology Including
ASP.NET/InfoPath (VS)
Auto generated, customizable ASP.NET Forms (SPD) - Modification
Can modify WF (VS)
Can’t modify WF using modification forms (SPD) - Association
Can be associated with multiple content types,
list and document libraries (VS)
Associated automatically with a single list at design time,
No other association possible (SPD) - Debugging
Yes
No (SPD) - Deployment
Must build package & Deploy WF using SharePoint Feature
technology (VS)
Automatically Deployed to associated list,
live Changes (SPD)
Tuesday, December 4, 2007
Setting Up Kerberos For MOSS 2007 Server
1. Configure Service Principle Names (SPN)
The first thing we need to do in order to enable Kerberos for SharePoint is configure Service Principle Names (SPNs) for our SharePoint service accounts (US\Srv_Moss2007) in Active Directory
SPNs are used by Kerberos to ensure that only certain accounts have permission to delegate a specific service on a user's behalf. An SPN needs to be configured for each service and address that the account needs to delegate for. SPNs are configured by using SetSPN.exe
Example for tester22 site:
Setspn –A HTTP/tester22.us.domain.net US\srv_moss2007
Setspn –A HTTP/tester22 US\srv_moss2007
Note: Remove away all the SPN for local host Trust for Delegation
In addition to setting the SPNs for each of your service accounts, you also need to trust each of the computer accounts and some of the service accounts for delegation.
2. Trusting for delegation means that the accounts are allowed to delegate on a user's behalf.
In order to trust for delegation you need to open Active Directory Users and Computers as a user with domain administration rights and follow these instructions
Process the following for “US\Srv_Moss2007”
Locate the account and click 'properties'
Navigate to the 'Delegation' tab
Choose 'Trust this user/computer for delegation to any service (Kerberos)'
3. Enable Kerberos on your web applications
In MOSS 2007, the switch between Kerberos and NTLM is very simple and is undertaken via Central Administration.
If you are creating your farm from scratch, be sure to set Central Administration itself to use Kerberos which you can set as part of the 'SharePoint Products and Technologies Configuration Wizard', however if the farm is pre-created you can easily enable Kerberos by following these steps:
Open Central Administration
Navigation to Application Management > Authentication Providers
Choose the web application you wish to configure from the drop-down in the top right corner (this includes the Central Administration web application)
Click on 'Default'
Set the authentication to Negotiate (Kerberos)
IISRESET
4. Enable Kerberos on your SSP
In this step you enable Kerberos on your SSP. Follow these steps:
Open Central Administration
Navigation to Application Management > Authentication Providers
Choose Web Application
Click on Zone Default
Under Edit Authentication, Section Integrated Windows authentication
Choose Negotiate (Kerberos)
Save and Close
5. Component Services Configuration
We need to set various permissions in Component Services. Follow these steps:
Open Component Services on the MOSS server
Navigation to Component Services > Computers > My Computer
Click on Properties (for My Computer) > Default Properties > Default Impersonation Level = Delegate
Navigate to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service
Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab
Edit Launch and Activate Permissions
Grant all three of your application pool account 'Local Activation' permissions.
Example:
US\MySiteAppPool
US\SSPAdminAppPool
US\PortalAppPool
6. Troubleshooting Kerberos
Issue these commands and retest
A. KList purge
In the Server as well as testing workstation issue the fallowing command to clear the Kerberos tickets
KList purge
Then answer with flag Y (yes)
B. DNS & NetBIOS State
Issue fallowing command on server as well as workstation
Nbtstat –R
Ipconfig /flushdns
The first thing we need to do in order to enable Kerberos for SharePoint is configure Service Principle Names (SPNs) for our SharePoint service accounts (US\Srv_Moss2007) in Active Directory
SPNs are used by Kerberos to ensure that only certain accounts have permission to delegate a specific service on a user's behalf. An SPN needs to be configured for each service and address that the account needs to delegate for. SPNs are configured by using SetSPN.exe
Example for tester22 site:
Setspn –A HTTP/tester22.us.domain.net US\srv_moss2007
Setspn –A HTTP/tester22 US\srv_moss2007
Note: Remove away all the SPN for local host Trust for Delegation
In addition to setting the SPNs for each of your service accounts, you also need to trust each of the computer accounts and some of the service accounts for delegation.
2. Trusting for delegation means that the accounts are allowed to delegate on a user's behalf.
In order to trust for delegation you need to open Active Directory Users and Computers as a user with domain administration rights and follow these instructions
Process the following for “US\Srv_Moss2007”
Locate the account and click 'properties'
Navigate to the 'Delegation' tab
Choose 'Trust this user/computer for delegation to any service (Kerberos)'
3. Enable Kerberos on your web applications
In MOSS 2007, the switch between Kerberos and NTLM is very simple and is undertaken via Central Administration.
If you are creating your farm from scratch, be sure to set Central Administration itself to use Kerberos which you can set as part of the 'SharePoint Products and Technologies Configuration Wizard', however if the farm is pre-created you can easily enable Kerberos by following these steps:
Open Central Administration
Navigation to Application Management > Authentication Providers
Choose the web application you wish to configure from the drop-down in the top right corner (this includes the Central Administration web application)
Click on 'Default'
Set the authentication to Negotiate (Kerberos)
IISRESET
4. Enable Kerberos on your SSP
In this step you enable Kerberos on your SSP. Follow these steps:
Open Central Administration
Navigation to Application Management > Authentication Providers
Choose Web Application
Click on Zone Default
Under Edit Authentication, Section Integrated Windows authentication
Choose Negotiate (Kerberos)
Save and Close
5. Component Services Configuration
We need to set various permissions in Component Services. Follow these steps:
Open Component Services on the MOSS server
Navigation to Component Services > Computers > My Computer
Click on Properties (for My Computer) > Default Properties > Default Impersonation Level = Delegate
Navigate to Component Services > Computers > My Computer > DCOM Config > IIS WAMREG Admin Service
Click on Properties (for IIS WAMREG Admin Service) and navigate to the Security tab
Edit Launch and Activate Permissions
Grant all three of your application pool account 'Local Activation' permissions.
Example:
US\MySiteAppPool
US\SSPAdminAppPool
US\PortalAppPool
6. Troubleshooting Kerberos
Issue these commands and retest
A. KList purge
In the Server as well as testing workstation issue the fallowing command to clear the Kerberos tickets
KList purge
Then answer with flag Y (yes)
B. DNS & NetBIOS State
Issue fallowing command on server as well as workstation
Nbtstat –R
Ipconfig /flushdns
Subscribe to:
Posts (Atom)