The following post covers issues I came across when configuring SharePoint 2010 to work with an Active Directory (AD) trust. In this scenario, SharePoint and user accounts are in domain A and a two-way transitive trust has been created with domain B. Domain B holds news users who need access to SharePoint.
The first issue was the error below, which occurred when setting permissions for AD users and groups from domain B using the People Picker.
“No exact match was found. Click the item(s) that did not resolve for more options“
As a two-way trust exists between the two domains and the web application is using Windows authentication, SharePoint should have been able to locate users and groups in the trusted domain. However, this wasn’t the case and I had to run the commands on this page http://technet.microsoft.com/en-us/library/cc263460.aspx. The STSADM –o setapppassword –password <password> command has to be run on every SharePoint server running the Windows SharePoint Services Web Application service. The stsadm.exe –o setproperty –pn peoplepicker-searchadforests –pv <list of forests or domains> -url <webapp> command is run on one SharePoint server running the Windows SharePoint Services Web Application.
The next issue occurred when using the Audience Picker to set an audience on a web part for a group from domain B. Unlike the People Picker which queries AD, the Audience Picker queries the user profile database for imported users. In this case I was able to search for the security group from the trusted domain, the group was listed as containing members, but the audience setting failed to work. This error was caused by a mismatch between the NETBIOS name of domain B and the FQDN, e.g. the NETBIOS name was DOMAINB-XY and the FQDN was DOMAINB.COM. In order to fix the problem I followed the steps listed here http://blogs.msdn.com/b/russmax/archive/2010/03/20/sharepoint-2010-provisioning-user-profile-synchronization.aspx. The basic steps are:
- Ensure Grant Replicate Directory Changes has been correctly assigned on domain B http://technet.microsoft.com/en-us/library/hh296982.aspx
- Set the NetBiosDomainNamesEnabled property to true for the User Profile Service Application
- Delete and recreate the AD connection within SharePoint for the import of users from domain B
- Import users from domain B.
I came across this error when I was attempting to import data from an Excel spreadsheet into a SQL database using SQL Server Integration Services (SSIS) 2005. The error occurs because by default the Excel driver only reads the first eight rows of the spreadsheet when it determines the column data type and data length.
If you have a spreadsheet where the first eight rows aren’t representative of the data in the spreadsheet, you can increase the number of rows that are sampled by editing the TypeGuessRows value under the following registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel
See here for more details http://technet.microsoft.com/en-us/library/ms141683(v=sql.90).aspx.
If you need to upgrade a server running Windows Server Standard to either the Enterprise, or Datacenter editions, it’s possible to do so online, without re-installing Windows.
Open an elevated command prompt and type DISM /Online /Get-CurrentEdition. This will return the current Windows version.
Type DISM /Online /Get-TargetEditions to list the Windows editions to which this server can be upgraded.
If you type DISM /Online /Set-Edition:ServerDataCenter you’ll get the message in the screenshot below. This is because even if you’re using a KMS server for internal activation, you have to provide a product key. Fortunately, Microsoft have a page that lists the KMS client setup keys http://technet.microsoft.com/en-us/library/ff793421.aspx. On this page you can find keys for multiple Windows Server versions.
Typing DISM /Online /Set-Edition:ServerDataCenter /ProductKey:xxxxxx will upgrade the operating system. All that’s required to complete the upgrade is a reboot.
As part of an operating system deployment task in System Center Configuration Manager 2007 R2 (SCCM), I needed to enable the .NET Framework 3.5.1 Feature on Windows Server 2008 R2. I thought it would be easy to do this as part of the task sequence, but it proved trickier than I expected.
I added a “Run Command Line” step and entered the command “Dism.exe /online /Enable-Feature /FeatureName:NetFx3 /LogPath:c:\Dism.log”. On its own this isn’t enough for the feature to be enabled. you must also tick the “Disable 64-bit file system redirection” in order for the feature to be enabled.