Sunday, April 15, 2012

'Document checked out' error on SharePoint Designer workflow

Issue:
Some times workflow stops due to an error. It says 'Error updating a list item' and the outcome says 'Document checked out'.

Reason:
Document gets locked when there are multiple fields set from the workflow simultaneously.

Fix:
Set the 'Checkout' action before the other action items in the workflow. After the updates, set the check in action. By wrapping the workflow actions with the 'check-out/check-in' actions document will be available for all the updates.

Friday, February 10, 2012

CoCreateInstance failed to create the control Error

Issue:


While trying to add 'Contact Selector' to the Infopath controls, you get the below error:


CoCreateInstance failed to create the control.
- The control may not be properly installed or registered.
- The control may have missing dependencies.
- Only controls implemented as InProc servers (.DLL or .OCX) are supported.
One more scenario for this issue to happen is, suddenly your InfoPath form template's contact selector will show 'X' symbol.. kind of image not found. When you open the InfoPath form that has the contact selector control, it prompts the error some thing like, "Infopath cannot open this form, because some of the controls are not rendered'

Reason:
Office suit, particularly Infopath got corrupted.

Fix:
Run the Office Diagnostics tool.
1. Open InfoPath 2007


2. Help -> Office Diagnostics

Tuesday, November 15, 2011

SharePoint 2010 File Name restrictions

SharePoint 2010 Content Naming rules:


Though the restrictions are documented at the above location, I wanted to take the bits from different blogs and make the information understandable to the general audience.

Folder Names and File Names
  1. Do not use - " # % & * :  <> ? \ / { } ~
  2. File names cannot be longer than 128 characters
  3. Do not use the period character consecutively in the middle of a file name. For example, "file..name.docx" is invalid.
  4. You cannot use the period character at the end of a file name
  5. You cannot start a file name with the period character
  6. Many other symbols are not recommended such as $^()-_=+[]`! (other international currency symbols and international symbols should be avoided in site names, but some are more acceptable in file names. Ascii is preferred when possible.
  7. File names and folder names may not end with the below. Becvause these are kind of reserved words:.files, _files , -Dateien , _fichiers , _bestanden , _file ,_archivos ,-filer,_tiedostot ,_pliki ,_soubory ,_elemei ,_arquivos ,
    _dosyalar ,_datoteke ,_fitxers,_failid
    ,_fails ,_bylos ,_fajlovi,_fitxategiak
Examples of Legal File Names
xyz.docx
abc_3454.doc
Long.Name.With.Dots.txt

Examples of illegal file names:
name%.wav.
multiple...dots.txt
lessthanfrst&last.mp3
questoin?.doc 

Site Naming rules 


  1. Not Allowed:   # { } % & " ~ + \ / : * ? " < >
  2. Avoid starting sites with an underscore (_) or with the period character.
  3. Site names can cause confusion and corruption if they have periods, apostrophes or commas
  4. They should not have consecutive periods or end with a period.
  5. You cannot use the period character at the end of a site name.
  6. Many other symbols are not recommended such as $^()-_=+[]`! (other international currency symbols and international symbols should be avoided in site names, but some are more acceptable in file names. Ascii is preferred when possible.
Examples of Illegal Site Names
Intranet/sites/AT & T
Intranet/sites/allow 10% me
Intranet/sites/_AUDI
Intranet/sites/#BMW
Intranet/sites/Carbs+Protiens

File and Folder name lengths

  1. Link list items are restricted to 256 characters and will truncate links to SharePoint documents (or anything else) with lengths longer than this.
  2. When storing files the structure and files (entire path including sites, folders, and file name) cannot add up to more than 260 characters or they will see an error message or form validation error with the explanation around the URL length.
  3. When using multi file upload interface: Make sure the total size of all your files is not greater than the upload limit set for your web application
upload size limits
To set the upload size to 200 megabytes, use the following syntax:
stsadm -o setproperty -pn max-file-post-size -pv 200

To view the current setting of the maximum file post size property, use the following syntax:
stsadm -o getproperty -pn max-file-post-size –url http://server_name

IIS Connection Timeouts

The default timeout for connections in IIS is 120 seconds (2 minutes). Depending on your maximum file size and how long it takes for the file to be uploaded, you may not need to change this setting. If, however, IIS is timing out when you upload large files, you can change this property to ensure that larger files can be uploaded successfully.

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
  2. Right-click the virtual server you want to configure, and then click Properties.
  3. Click the Web Site tab.
  4. In the Connections section, in the Connection timeout box, type the number of seconds you want IIS to wait before timing out.
  5. Click OK.
Default chunk size for large files:

Sharepoint default chunk size is set to 5MB, this means that if a client tries to open a document of 50MB and the chunk size is 5MB, the document is divided and retrieved in 10 chunks. Each chunk will be loaded into the memory of both the WFE handling the request and the SQL Server
  1. stsadm -o setproperty -pn large-file-chunk-size -pv 1073741824
  2. IISReset

Thursday, November 10, 2011

The form cannot be submitted to the Web server

Issue definition:
Whenever you submit an infopath form "The form cannot be submitted to the Web server either because your computer is offline or because the host server is currently unavailable. If this problem persists, contact your network administrator"

Reason:

Ther are several reasons for this.
1. ISA server not configured properly
(or)
2. DNS not Configured Proerly
(or)
3. https ssl mappings not done properly using Alternate Access mappings

The above are the high level reasons for this issue. But, In our case, we deleted the root site (http://servername/) by mistake and this issue started bugging. InfoPath needs this root site to host the Infopath applications. When the form is actually published, SharePoint marks this location as the host.

Fix:


Create a root site. Below are the steps:
1. Access the SharePoint Central administratoin
2. Click on the 'Application Management' tab
3. Click on 'Define manged Paths'
4. in the Path field, enter "/"
5. select 'explicit inclusion' from the drop down and 'OK'

Monday, October 10, 2011

SharePoint People Picker Integration issues

Recently my business users complained that they can not add users to the site as they can not search the user names using the people picker. Iwent to SSP -> User Profiles and My Sites -> User Profiles and Properties ->View Import Connections. Every thing was good. I started a full import to make sure the user profiles are up to date. It completed in about an hour and imported users from the actual domain.

The problem we run into is that I was able to find the users from the "domainA" domain on which the moss server is located. I found out that by default People Picker can only find people in the resource domain - the domain that MOSS servers are in. For other domains/forests, you'll need to run the following command:

Stsadm.exe –o setproperty –pn peoplepicker-searchadforests –pv -url

The format of is a list of

forest:DnsName,LoginName,Password
or
domain:DnsName,LoginName,Password

separated by semicolon.

If they are trusted domains/forests, then it is not necessary to pass in the LoginName or Password, just in the format of
forest:DnsName
or
domain:DnsName

If the Password is specified in the forest:DnsName,LoginName,Password or domain:DnsName,LoginName,Password,
please run the below:

stsadm.exe -o setapppassword -password first. could be any string.
We will use to encrypt the Password in domain:DnsName,LoginName,Password or forest:DnsName,LoginName,Password and stored the encrypted Password in the database.
Also, please use the same to run stsadm.exe -o setapppassword -password on all machines where SharePoint is installed. For different web farm, please use different .

SharePoint and AD

This post references the below article:
http://technet.microsoft.com/en-us/library/cc263449(v=office.12).aspx


It is good to understand how AD, domains, forests and trusts are working in order to get your people-picker working correctly (displays what you effectively want to see), rapidly (does not take ages to return a result) and reliably (its behavior is predictable and persistent over time). I am often surprise by the fact that very few SharePoint specialists really know about the windows and AD internals, this often lead to improper people picker configuration.
How it works, with the default configuration.



The people-picker is a SharePoint interface responsible for querying repositories for identities or groups in order to grant them permission in the SharePoint application. It is implemented as part of the WFE role, this means that when you’re using it, the WFE you’re connected to will attempt to contact AD in order to returns items matching your query’s criteria.


Here is, step by step, how it exactly works from an AD/Windows point-of-view:
A users submit a query to the people-picker
The WFE performs a DNS query in order to locate a domain controller hosting the Global Catalog Service. There are actually two possible DNS queries:
The first query will include the server’s Active Directory site name, in order to locate a domain controller that reside on the same site or “covers” it (does not reside in the same site but is configured as a candidate to receive request from originating from that site).If that first query succeeds, there’ll be no second.
It it fails and the DNS reports that there is no such name, a second query will take place without any reference to the server’s site.

with an IP address of a DC in hand, SharePoint will initiate a connection from a local random port to the remote port 3368 (Global Catalog LDAP over TCP) against the select domain controller. This first connection, which is is anonymous, will report to the SharePoint server extra information over the DC it contacted. It will include various LDAP information, the its exact capabilities as well as the authentication mechanism it supports. This entry point is known as the “Root” or “RootDSE”

Once SharePoint know how to “talk” to AD, it will perform a query whose part of the parameters are based on the users' input. This query is actually programmatically powered by the System.DirectoryService Namespace. since that query is made against the Global Catalog Service, it can only use a subset of the AD attribute (known as the partial attribute set). the exact list of attributes depends on the Windows version of the DC and on the presence of schema extension (MS Exchange, OCS or custom…). If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the IIS application pool the SharePoint web application runs under. It can be Local system or Network Service (then DOMAIN\SERVERNAME$ is used) or a specified user
SharePoint displays the results to the user

The query, as stored in the code:
(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))((name={0}*)(displayName={0}*)(cn={0}*)(mail={0}*)(sn={0}*)(SamAccountName={1}*)(proxyAddresses=SMTP:{0})(proxyAddresses=sip:{0}){2}))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))((name={0})(displayName={0})(cn={0})(mail={0})(samAccountName={0})(proxyAddresses=SMTP:{0})(proxyAddresses=sip:{0})))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))((mail={0})(proxyAddresses=SMTP:{0})))"), new SearchParameter("(&(objectCategory=group)((name={0}*)(displayname={0}*)(cn={0}*)(SamAccountName={1}*)(mail={0}*)(proxyAddresses=SMTP:{0}){2}))", "(&(objectCategory=group)((name={0})(displayname={0})(SamAccountName={0})(mail={0})(proxyAddresses=SMTP:{0})))", "(&(objectCategory=group)((mail={0})(cn={0})(proxyAddresses=SMTP:{0})))"), new SearchParameter("(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)((name={0}*)(displayname={0}*)(cn={0}*)(SamAccountName={1}*){2}))", "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)((name={0})(displayName={0})(cn={0})(samAccountName={0})))

The query criteria in clear:
A user or a group
If it is user, at least of of the following attribute must begin with the input the user provided: name, displayName, cn, mail, sn, SamAccountName, proxyAddresses (with SMTP or sip)
It it is a user it must not be disabled
If it is a group, at least of of the following attribute must begin with the input the user provided: name, displayname, cn, SamAccountName
if it is a group, it must be a security group (domain local, global or universal), not a distribution group

The following attributes are requested to be returned for each record found:
objectSID
mail
displayName
title
department
proxyAddresses
cn
samAccountName
groupType
userAccountControl
distinguishedName

And finally, the following server controls are specified:
LDAP_PAGED_RESULT_OID_STRING: Page the results and get 20 results per page
LDAP_SERVER_DOMAIN_SCOPE_OID: Instructs the DC not to generate LDAP continuation references in response to a search operation.
Key points:
By default, SharePoint only knows about the AD forest its server(s) belong(s) to
SharePoint uses DC locator DNS records to locate a DC hosting the Global Catalog Service
It issues a queries using the LDAP-like dialect against that Global Catalog Service using System.DirectoryService Namespace
There is no “security trimming” per se. The queries returns the results based on what the IIS application pool identity is allowed to see, not the end-user’s identity

Still unclear to me:
In the case (non default and not recommended), in the case the IIS Application pool runs under the context of a user from another domain, which domain controller of which domain will be used?

Querying Additional Forest or Domains
In this section, I will cover the most frequent configuration: the SharePoint server belongs to a forest and/or domain that has 2-way trusts established with other forests or domain. The accounts of the users accessible SharePoint therefore belong to those trusted domains and since the trust is in both direction, the identity of the IIS application pool is also capable of authenticating against those trusted domains.

In order to instruct SharePoint to query those trusted domain or forests, the command “STSADM.exe -o setproperty -pn peoplepicker –searchadforests” must be used. But it seems like many people are getting confused, for good reasons, with the exact syntax of the parameter to be passed.

first you keep to gather the following information:
Do you want to query a forest (in this case, you’ll need a forest-trust) or a domain (in this case, an external trust is sufficient)
What is the DNS name of the forest you wish to query (also the DNS name of its root domain) or what is the DNS name of the
Then, based on the information above, you can assemble the parameter correctly. The configuration of each forest or domain to be queried must be separated with a semi-colon and inside the configuration, the first word must be forest: or domain: and it must be followed by a valid DNS name. Example:
STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:dune.local;domain:carthag.local;domain:tuono.local”
Key points:
The DC Locator process used with the standard configuration is still applicable BUT is extended beyond the local forest boundaries. This means that the SharePoint servers must be able to resolve names of remote forests/domains domain controllers (SRV records and A records)
Also, Active Directory Sites should be identically named between forests, otherwise, SharePoint may not target the “closest” domain controller
If you use “Selective authentication” or “SID Filtering” in order to restrict authentication through trusts, you must make sure that the IIS application pool identity is allowed to authenticate against the remote forest/domain it queries
Needless to say that if there are firewall between SharePoint and the remote forest/domains, they must be configured adequately
As I said above,if the “forest” argument is specified, a forest-trust must be in place
If you still wish to query the forest/domain SharePoint belongs to, you’ll have to add it as part of the parameter too
If you configure a forest to be queried, it is not necessary to declare all or some child domains separately, they will be queried anyway
If “forest” is specified, the Global Catalog Service will be used to perform the query, if “Domain” is specified, the LDAP service will be used instead. Global Catalog (GC in short) can query all objects inside a given forest BUT knows only, as stated above, about a limited set of attributes while LDAP knows about ALL attributes but its boundaries is the domain it is targets
Do not forget to perform IISRESET on each SharePoint server where the configuration must be applied

Still unclear to me:
I have a great level of certainty that the query against each forest/domain are not performed in parallel, at least not the DNS part
The One-way trust Configuration

This configuration is identical to the above except that since the IIS application pool identity is unable to authenticate against the remote forest/domain due to the limitation set by one-way trust, alternate credentials must be specified. Those credentials must be from the forest/domain to be queried or from a trusted domain, as long as it is allowed to authenticate and is not denied to logon remotely.

The tough part of the job in this case is to apply the configuration.
first, a key must be generated in order to encrypt/decrypt the alternate credentials that will be used, in order to do so, you have to run the command hereunder on every SharePoint server where the people picker will be used (shortcut: do it on all servers!):

STSADM.exe -o setapppassword -password MYPASSWORD. where MYPASSWORD is the key –> it makes sense that the more complex, the better but is is not ruled by the Windows password policy

Secondly, you have to provide the list of forest/domains to be queried as well as the credentials to do so. Each block is separated by semi-colons and each element in a block is separated by comma. Example:
STSADM.exe -o setproperty -pn peoplepicker–searchadforests –pv “forest:dune.local,DUNE\PAULA,PasswordOfPaulA;domain:carthag.local,CARTHAG\Gurney,PasswordOfGurney;domain:tuono.local,TUONO\SHANIA,PasswordOfShania”
Key points:
Make sure you have valid credentials for each forest/domain
Make sure each forest/domain element is correctly structured
Do not forget to perform IISRESET on each SharePoint server where the configuration must be applied
Troubleshooting Tips
Useful tools
NTLTEST command-line: (part of the windows Server 2008 Support tools or built-in Windows Server 2008)
Wireshark network capture utility
LDP.exe simple LDAP client (part of the windows Server 2008 Support tools or built-in Windows Server 2008)
Active Directory User and computer (ADUC) Console
ADInsight from MS Sysinsternals (not super reliable alas)
Global Approach
The most straightforward way to trace the behavior of the people picker is to take a network capture while performing the search from the Web GUI, taking care of flushing the DNS resolver cache (ipconfig /flushdns). Take this capture of the WFE your target with your tests and filter the results as follows:
Apply a display filter to show only DNS requests, you should see requests like the following:
If you attempt to query a domain: _ldap._tcp.Site-Name._sites.domain.local: type SRV, class IN (first attempts, in order to locate a DC in the same site) or _ldap._tcp.domain.local: type SRV, class IN (any DC in that domain, regardless of the site)
If you specified to query a forest, you should see _gc instead of _ldap
If you don’t see those DNS request or if you see them but they fail, make sure the SharePoint servers are able to resolve names from remote domains ad are configured with the correct DNS Servers and optionally with a list of suffixes
Once name resolution is working fine, go back to the capture and make sure you see LDAP (port 389) or GC (same as LDAP but on port 3268).
for each domain or forest, you should see a “bindRequest” with a successful response followed by a “seachRequest” followed by a successful response as well. drill-down into the search request for the details about the query submitted: the filter and conditions applied in particular
Retrieving the server’s AD site
Execute the command “NLTEST /dsgetsite”. It should return the AD site the SharePoint server belongs to. If it does not, there is a serious AD configuration problem ;)
Retrieving a DC for a given domain
Execute the command “NLTEST /dsgetdc:mydomain.local
If the list of flags it return includes the following, you’re ok:
CLOSE_SITE= the DC is in the same AD site as the SharePoint server or is “covering” that site
LDAP: the DC is LDAP server (all DCs are but must advertise it)
GC: the DC is also global catalog (NOT all DCs are but if they are, they must advertise it too)
Note: Other information returned by the command might also be useful for troubleshooting: Name and IP address of the DC…

Simple LDAP connection test
1. On the SharePoint server, start ldp.exe
2. Go to the menu “Connection” and click “Connect”. Enter the IP or the host name of the remote DC. You should test with a FQ host name in order to test DNS too. Select port 389 for LDAP or 3268 for GC. If it works, it will return a list of server-related information
3. repeat this test for each DC SharePoint would potentially target
Testing the credentials to connect to a remote domain using LDAP (one-way trust scenario in particular)

If the test above works, proceed to this one:
1. Return to the menu “connection” then click “Bind” then enter the credential of the remote domain to be browsed (including the domain name in the 3rd textbox
2. If it fails, you’ll see a message such as
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User=’myuser’; Pwd= ; domain = ‘mydomain’.}
Error <49>: ldap_bind_s() failed: Invalid Credentials.
3. If it succeeds, it will report
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User=’myuser’; Pwd= ; domain = ‘mydomain’.}
Authenticated as dn:’myuser’.
Top People-Picker Reliability/Performance Killers
The more forest/domains there are two query, the slower it will be to get results
Problematic Name Resolution Process: In order to resolve DC locator records, Windows will exhaust all possible name resolution methods, from DNS to broadcast… And this for each declared forest/domain
Unresponsive DC brings major slow down
Suboptimal/Inconsistence AD Site configuration: Site-awareness is a key factor, this makes sure SharePoint always query the nearest DC
Network devices/Security devices breaking the TCP traffic: from broken NIC to firewall, anything generating TCP retransmit or “forcibly closing” connections
Load on Active Directory/Domain controller or security settings on the domain controller (preventing DoS attacks for example)
If custom filter is used: Improperly written filter: make sure the complexity of criteria remains reasonable, only indexed attributed are queried and of course if the GC is used, only attributed that are part of the partial attribute set
Additional information’s
MS TechNet LDAP Query Basics
MS TechNet Select users from multiple forest domains
MS TechNet Peoplepicker-searchadforests: Stsadm property (Office SharePoint Server)
MS TechNet Active Directory Trust Types
MS KB How to query Active Directory by using a bitwise filter
Joel Oleson Multi Forest/Cross Forest People Picker peoplepicker-searchadcustomquery
Bill Baer Configuring SharePoint Products and Technologies for Cross-Forest Deployments
What’s next?
In the next posts, I will cover:
Additional filtering capabilities of LDAP searches
Detailed configuration for each scenario
how people picker is related to authentication and profile import (MOSS only)
Guidance to optimize people-picker in different scenario’s
And cut!

Tuesday, February 23, 2010

AJAX chart integration with a Sharepoint list

1. Have the jqury installed to the local site or just refer the google API.
2. Type the following code in you CEWP's source!

<div id="jLoadMe" class="content"><strong>Name to display</strong></div>
<script type="text/javascript">if(typeof jQuery=="undefined"){
var jQPath=http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/;
document.write("<script src='",jQPath,"jquery.js' type='text/javascript'><\/script>");}
</script>
<script type="text/javascript">
$("document").ready(function(){
var arrayList=$("td.ms-gb:contains(':')");
var coord= new Array();
var labels= new Array();
$.each(arrayList, function(i,e) {
var MyIf= $(e).text();
var txt= MyIf.substring(MyIf.indexOf('(')+1,MyIf.length-1);
// Extract the 'Y' coordinates
coord[i]=txt;
var txt1= MyIf.substring(MyIf.indexOf(':')+2,MyIf.indexOf("(")-1);
// Extract the labels
labels[i]=txt1+"("+txt+")";
//add also coordinates for better read });
var txt= coord.join(",");
var txt1= labels.join("");
// Adjust Chart Properties below - See Google Charts API for reference
var vinc= "<IMG src='http://chart.apis.google.com/chart?cht=p3&chs=750x200&chd=t:"+txt+"&chl="+txt1+"'/>"; $("#jLoadMe").append("<p>"+vinc+"</p>")});
</script>