On any SharePoint 2010 site, if we have lookup lists that contain over 20+ items and if the user tries to create a new item in the in that list, they are unable to see the lookup value from the lists as it is positioned in a different place in the list. This issue is observed in IE 8, IE 9 and IE 10.

Cause
This seems to be an issue with identifying the correct x and y coordinates when showing the filtered items in the dropdown lists.

Resolution

We do have a workaround which can be implemented on any environment where we have the lookup list with more than 20+ items.

Below are the steps to be followed to implement the workaround:

1. We need to open the site in SharePoint Designer 2010.

2. Go to the List which is using the lookup list items.

3. Modify the newform.aspx using SPD 2010.

4. In the modify web part and in the "miscellaneous" section, check the option, "UseStandardControl" and apply the changes.

5. Test the new item creation on the target list where we have the lookup columns being created and everything works perfectly fine

6. We have the dropdown positioned in the expected place and no issues with the display.

7. We can also select the lookup list item without a double-click.

8. Modify the webpart properties for the editform.aspx page as well in SPD.

9. Now, when we edit the item, we do not have the lookup issue anymore observed in the newform.aspx and editform.aspx page.

Timer service crashes every second -- it starts and stops continuously on some of the servers in the farm. We see the below event viewer errors:

Log Name:      System
Source:        Service Control Manager
Date:          [Date and Time]
Event ID:      7031
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      <machine name>
Description:
The SharePoint 2010 Timer service terminated unexpectedly.  It has done this 957 time(s).  The following corrective action will be taken in 30000 milliseconds: Restart the service.
Event Xml:
<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
    <EventID Qualifiers="49152">7031</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8080000000000000</Keywords>
    <TimeCreated SystemTime="2013-07-09T01:40:34.089553100Z" />
    <EventRecordID>291829</EventRecordID>
    <Correlation />
    <Execution ProcessID="504" ThreadID="2312" />
    <Channel>System</Channel>
    <Computer>machine name</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">SharePoint 2010 Timer</Data>
    <Data Name="param2">957</Data>
    <Data Name="param3">30000</Data>
    <Data Name="param4">1</Data>
    <Data Name="param5">Restart the service</Data>
  </EventData>
</Event>

Log Name:      System
Source:        Service Control Manager
Date:          [Date and Time]
Event ID:      7036
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      <machine name>
Description:
The SharePoint 2010 Timer service entered the running state.
Event Xml:
<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
    <EventID Qualifiers="16384">7036</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8080000000000000</Keywords>
    <TimeCreated SystemTime="2013-07-09T01:40:31.265935000Z" />
    <EventRecordID>291828</EventRecordID>
    <Correlation />
    <Execution ProcessID="504" ThreadID="2312" />
    <Channel>System</Channel>
    <Computer>machine name</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">SharePoint 2010 Timer</Data>
    <Data Name="param2">running</Data>
    <Binary>53005000540069006D0065007200560034002F0034000000</Binary>
  </EventData>
</Event>

Cause

Malformed OWSTIMER.EXE.config file on one of the servers.

RESOLUTION

We found the below call stack in the ULS logs:

An exception occured while trying to acquire the local farm: System.TypeInitializationException: The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Data.SqlClient.SqlConnectionFactory' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Data.SqlClient.SqlPerformanceCounters' threw an exception. ---> System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize ---> System.Configuration.ConfigurationErrorsException: '?' is an unexpected token. The expected token is ''>''. Line 1, position 20. (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE.Config line 1) ---> System.Xml.Xml..

Based on the above error, we went to the server and navigated to the file C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\OWSTIMER.EXE.Config.

We found the below entry in the file:

<?xml version="1.0"? encoding="utf-8" ?>

Compared in-house and the actual entry is as below:

<?xml version="1.0" encoding="utf-8" ?>

We removed the extra question mark (?) before "encoding" and saved the changes.
Then we restarted timer service.
Waited for about 5-10 minutes and there is no crash observed.
Also, the event viewer doesn't have the event IDs 7031 and 7036 anymore.
We also were able to get the mails waiting in the mail drop folder flushed as soon as the timer service was stable.

Managed Metadata is a hierarchical collection of centrally managed terms that you can define, and then use as attributes for items in Microsoft SharePoint Server 2010.

This service is now more advanced with the option to use the same managed terms across web applications and site collections which was a cumbersome process in MOSS 2007. More about that in the later parts of this blog.

Let me touch upon some of the terms used in this blog for better understanding.

A term is a word or a phrase that can be associated with an item in SharePoint Server 2010. A term set is a collection of related terms. You can specify that a SharePoint Server 2010 column must contain a term from a specific term set. Managed metadata is a way of referring to the fact that terms and term sets can be created and managed independently from columns.

Local term sets are created within the context of a site collection. For example, if you add a column to a list in a document library, and create a new term set to bind the column to, the new term set is local to the site collection that contains the document library.

Global term sets are created outside the context of a site collection. For example, the term store administrator could create a term set group named Human Resources and designate a person to manage the term set group. The group manager would create term sets that relate to Human Resources, such as job titles and pay grades in the Human Resources term set group.

When you enable managed metadata in your SharePoint Server 2010 application, a managed metadata service and connection are created automatically. The service identifies the database to be used as the term store, and the connection provides access to the service. When you create new managed terms, or when users add enterprise keywords, these terms are stored in the database that is specified in the managed metadata service.

In addition to sharing managed metadata, you can also use the managed metadata service to share content types. By creating a new managed metadata service and specifying a site collection as the content type hub, you can share all content types in the site collection’s content type gallery.

You can create multiple managed metadata services, and share multiple term stores and content types from multiple site collections. However, each managed metadata service must specify a different term store. When you specify a nonexistent database for the term store, a new database is created.

For detailed steps on how to create/manage a Managed Metadata Service, visit https://technet.microsoft.com/en-us/library/ee530392.aspx 

Term Store is the database in which the managed metadata is stored.

Content types in SharePoint 2010 are used in the same way they were in WSS 3.0. You still have columns associated with the content type and you can setup policy based on a content type.

Note: The workflows associated with content types lose the association once the content types are republished and hence are not supported. It is better to create the workflow in the list in the target site collection.

In MOSS 2007, you would have to create or write an application to share content types between web applications.

OVERVIEW OF PUBLISHING PROCESS:

What has changed in SharePoint 2010 is content types can now be reused; they are no longer confined to the site where they were created. You can think of reusable content types as enterprise content types.

In SharePoint 2010, we have a feature called Content Type Hubs. This is a central location where you can manage and publish the content types. Since this is centralized, you can get the updates on the content types as and when they are updated!

TIP: As long as the web app uses the same content type hub from the MMS service app, it can receive the content types from the hub.

Content Types Synchronism is done by 2 Timer Jobs that are executed in the background.

They are:

a. Content type Hub: This tracks content type log maintenance and manages unpublished content types. This is not a per-web app job, but is a centralized timer job for content types.

b. Content Type Subscriber: This retrieves content types packages from the hub and applies them to the local content type gallery. This is more of a per web-app content type timer job.

Note: Both the above jobs are configurable based on the requirement.

We have specific error logging available for content types.

The first step to have the error logging to be enabled, we need to have the content type hub specified in the properties of MMS application.

Once this is specified, we can go to the settings page of the content type hub site collection and we will now be able to see, “Content type service application error log” and “Content type publishing”.

There are two different kinds of reports you can use to identify errors with content type publishing. The Content type service application error log, which is available on sites that are hubs for content type publishing, captures publishing error information for subscriber sites. The Content type publishing error log report captures publishing error information for a site.

a. If you are working on a hub site that publishes content types to other site collections, you can use the Content type service application error log reports to review publishing error information for subscriber sites.

You must be a Site Collection Administrator to view the Content type service application error log.

1.Go to the top-level site in the site collection that is functioning as a hub for content type publishing.

2.On the Site Actions menu Site Actions Menu, click Site Settings.

3.On the Site Settings page, under Site Collection Administration, click Content type service application error log.

b. If you are working on a site that subscribes to content types that are published from a hub site, you can use the Content type publishing error log.

You must be a Site Collection Administrator to view the Content type publishing error log.

4.Go to the top-level site in the site collection for which you want to view content type publishing errors.

5.On the Site Actions menu Site Actions Menu, click Site Settings.

6.On the Site Settings page, under Site Collection Administration, click Content type publishing.

7.Click the link titled Content type publishing error log.

That’s it from me for now folks… Ciao!!!

1. Difference between PSConfig wizard and PSConfig command line:

A: Both are quite similar except for the part where there are fewer commands being run in the command line vis-à-vis the PSConfig UI. In the command line, you have the option to force the upgrade. Also, you have separate commands to perform separate functions which is of course not possible via UI. Refer https://technet.microsoft.com/en-us/library/cc263093.aspx for the available PSConfig command lines.

2. Is it mandatory to run PSConfig after a patch/security update has been installed in the SharePoint farm?

A: Yes, it is mandatory to run PSConfig (UI/Command line) after every patch/security update has been installed on the SharePoint servers. Most of the security patches may not have the mandatory to run PSConfig, but we recommend that you run the wizard or command line every time to ensure that the corresponding .dlls get updated as and when patches are released. When a patch gets installed on the server, only the file system level update takes place. When we run PSConfig, it updates the database as well as it is a necessary to have the database and the SharePoint servers in sync at all times. We will run into issues in the future if PSConfig has not been run as this will result in an unstable farm.

3. Is there a particular order in which the PSConfig has to be run?

A: Yes, we need to start with the server hosting the Central Administration (CA) site first and then move to the other servers in the farm. This order is required as we need to first upgrade/update the Config database which holds the entire farm configuration details. Although the binaries/patches can be run in any particular order, we recommend that you first begin with the server hosting Central Administration first and then move to the other servers in the farm.

IMPORTANT: Always ensure that you finish installing binaries/patches on all the SharePoint servers in the farm successfully and only then start the PSConfig (UI or Command line).

4. PSConfig wizard failed on the CA site hosted server. Shall I try to update the other servers and then re-visit the CA server?

A: No. Please ensure that the CA server gets upgraded first. We need to look into the PSCDiagnostics logs or the Upgrade.log (whichever is available) and fix the error on the CA server first. Then, we will need to move on to the others servers in the farm. Even if PSConfig were to fail on any 1 server in the farm, do not move ahead with the other servers without fixing the error on the failed server. This can result in other potential issues with the failed server.

TIP: You can go to the default location C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Logs and check the upgrade.log or the PSCDiagnostics log file. In case you are unable to find the logs in the default location, you can go to Central Administration –> Monitoring –> Configure Diagnostic Logging –> Scroll down and in the “Trace log” section, the path will be specified.

5. Do we have to install the patches for both Microsoft SharePoint Foundation 2010 (MSF 2010) as well as Microsoft SharePoint Server 2010 (MSS 2010) like we used to for MOSS 2007?

A: No, it is not required to run both the patches. If you have MSS 2010, you need to run the patches only for MSS 2010 and then run PSConfig (UI/Command line) to complete the farm upgrade.

6. I have a lot of customization on my SharePoint 2010 farm. How do I ensure that I don’t lose the customization?

A: Whenever there is any patching to be done on the SharePoint farm, we need to first have the database backups and take backups of the Virtual directories (Inetpub folder) which has the web.config customizations. Also, if you have any customizations made on the OOB files, please take a backup of all the required files as PSConfig will re-write the OOB files to its original state. Note: Ideally, it is not recommended to modify the OOB files for just this reason. It is better to make a copy of the OOB file and modified the copy and not the original file.

You can refer https://msdn.microsoft.com/en-us/library/bb803457.aspx which although deals with MOSS 2007, but is also applicable for SharePoint 2010 regarding the supportability for modifying built-in files in SharePoint.

7. What are the preparations to be made before I start running the binaries and then run PSConfig on the SharePoint farm?

A: There are a few points to keep in mind before we start patching the SharePoint environment. Below are the key points:

• Have backups taken of the databases – all the databases including Config and Admin content. Use the following references to take backups with the SharePoint inbuilt tools: https://technet.microsoft.com/en-us/library/ee428316.aspx 
• You may also have 3rd party utilities to backup your data, however, we recommend that you also use the SharePoint tools listed in the above technet article to backup your data additionally. This helps in easy restore of data.
• Take backups of your customization (custom features/solutions, inetpub folder, 14 Hive (14 folder where the files are stored). Refer https://technet.microsoft.com/en-us/library/ee748642.aspx for backing up customization.
• Make sure that the backups you have taken have not failed for some reason before starting with the installation of patches.
• Always test the patches first on a test/staging/dev environment before applying it in production directly. This will ensure that you are aware of any changes that might incur with your customization.
• When ready to install the patches in the production, ensure that you have a long maintenance window (preferably during weekends or during holidays to reduce the user impact).
• Make sure that you are using the service accounts to perform the patch updates so that you don’t run into any permission issues while running PSConfig (UI/Command line).
• Turn off the WWW Publishing service on all the servers (disabled state in the services.msc) so that no user can access the site during the maintenance window.
• Do not have any scheduled backups or crawls or any other jobs scheduled during the maintenance window. This can slower the upgrade process and also result in failures in accessing the databases during the upgrade process.

This sums up the very commonly asked questions. Enjoy patching and upgrading your SharePoint 2010 farm!!!