Friday, July 11, 2014

'Form' is an ambiguous reference between 'System.Windows.Forms.Form' and 'Microsoft.SharePoint.Client.Form'

When I try to use the SharePoint 2013 Client Object model in Windows Application I was getting the following error.

"'Form' is an ambiguous reference between 'System.Windows.Forms.Form' and 'Microsoft.SharePoint.Client.Form'"

Reason is there is a conflict between ‘System.Windows.Forms.Form’ and ‘Microsoft.SharePoint.Client.Form’

Solution:
Just after  changing the code

To

public partial class MainForm : System.Windows.Forms.Form
    {
        public MainForm()
        {
            InitializeComponent();
        }

From 

public partial class MainForm : Form
    {
        public MainForm()
        {
            InitializeComponent();
        }

Problem fixed. 

Monday, June 23, 2014

Windows Phone Emulator is unable to create the virtual machine:

Windows Phone Emulator is unable to create the virtual machine:

Couldn't change Processor of the virtual machine: 'Emulator 8.1 720P 4.7 inch....' failed to modify device 'Processor'. (Virtual machine ID {GUID})

Cannot assign the specified number of processors for virtual machine 'Emulator 8.1 720P 4.7 inch....' is out of range. The range is 1 through 1. (Virtual machine ID GUID)


Solution:

For VMWare, - click on the Edit Virtual Machine Settings and Change the Processor from 1 to more.


Wednesday, May 21, 2014

Restoration of the configuration database by using the built-in backup and restore functionality is not supported in SharePoint products

After having a technical discussion with on the client, I came to notice the key aspect of SharePoint Config DB. Thanks SW :)

I never noticed this specific characteristics of Config DB

We do not support restoration of the configuration database in SharePoint products using the built in backup and restore functionality.

If you restore the configuration database, data in the configuration database will not be synchronized with data in other SharePoint databases. If this data is not synchronized, users may experience various random errors.

For example, a Windows SharePoint Services 3.0 content database may contain data about a newer site. If the configuration database does not contain information about this site, the site is orphaned.

http://support.microsoft.com/kb/948725/en-us

happy learning... 

Sunday, December 01, 2013

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category:    Office Server Shared Services
Event ID:    6482
Date:        2/12/2013
Time:        4:39:40 PM
User:        N/A
Computer:    "SERVER NAME"
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (75d4a317-f4ef-4afb-a3c6-c907afccceba).

Reason: Cannot open database "SharedServices_DB" requested by the login. The login failed.
Login failed for user 'CORP\SERVERNAME$'.

Techinal Support Details:
System.Data.SqlClient.SqlException: Cannot open database "SharedServices_DB" requested by the login. The login failed.
Login failed for user 'CORP\SERVERNAME$'.
   at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.SqlClient.SqlConnection.Open()
   at Microsoft.Office.Server.Data.SqlSession.OpenConnection()
   at Microsoft.Office.Server.Data.SqlSession.ExecuteNonQuery(SqlCommand command)
   at Microsoft.Office.Server.Administration.SharedObjectStore.Initialize()
   at Microsoft.Office.Server.Administration.SharedObjectStore.GetObject[T]()
   at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedObjectStore.GetObject[T]()
   at Microsoft.Office.Server.Administration.SharedApplicationCollection`1.GetValue(SharedResourceProvider sharedResourceProvider)
   at Microsoft.Office.Server.Administration.SharedApplicationCollection`1.get_Item(SharedResourceProvider sharedResourceProvider)
   at Microsoft.Office.Server.ServerContext.GetApplication[S,T](String name)
   at Microsoft.Office.Server.Search.Administration.SearchContext..ctor(ServerContext serverContext, Boolean cached)
   at Microsoft.Office.Server.Search.Administration.SearchDataAccessServiceInstance.Synchronize(Boolean bCalledFromSSI)
   at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
   at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

---
Solution:


Below is the step by step provided by Microsoft in this KB Article for doing this:
  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder
    In Windows Server 2008, the configuration cache is in the following location:
    Drive:\ProgramData\Microsoft\SharePoint\Config
    In Windows Server 2003, the configuration cache is in the following location:
    Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
    Locate the folder that has the file "Cache.ini"
    (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
  3. Back up the Cache.ini file.
  4. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
  5. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  8. Start the Windows SharePoint Services Timer service
  9. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  10. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
- See more at: http://www.social-point.com/sharepoint-2010-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-search-administration-searchserviceinstance#sthash.d9rBKjLc.dpuf



Below is the step by step provided by Microsoft in this KB Article for doing this:

    Stop the Windows SharePoint Services Timer service (Found in Windows Services)
    Navigate to the cache folder
    In Windows Server 2008, the configuration cache is in the following location:
    Drive:\ProgramData\Microsoft\SharePoint\Config
    In Windows Server 2003, the configuration cache is in the following location:
    Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
    Locate the folder that has the file "Cache.ini"
    (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
    Back up the Cache.ini file.
    Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
    Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
    Double-click the Cache.ini file.
    On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
    Start the Windows SharePoint Services Timer service
    Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.








Below is the step by step provided by Microsoft in this KB Article for doing this:
  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder
    In Windows Server 2008, the configuration cache is in the following location:
    Drive:\ProgramData\Microsoft\SharePoint\Config
    In Windows Server 2003, the configuration cache is in the following location:
    Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
    Locate the folder that has the file "Cache.ini"
    (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
  3. Back up the Cache.ini file.
  4. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
  5. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  8. Start the Windows SharePoint Services Timer service
  9. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  10. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
- See more at: http://www.social-point.com/sharepoint-2010-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-search-administration-searchserviceinstance#sthash.d9rBKjLc.dpuf
Below is the step by step provided by Microsoft in this KB Article for doing this:
  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder
    In Windows Server 2008, the configuration cache is in the following location:
    Drive:\ProgramData\Microsoft\SharePoint\Config
    In Windows Server 2003, the configuration cache is in the following location:
    Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
    Locate the folder that has the file "Cache.ini"
    (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
  3. Back up the Cache.ini file.
  4. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
  5. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  8. Start the Windows SharePoint Services Timer service
  9. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  10. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
- See more at: http://www.social-point.com/sharepoint-2010-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-search-administration-searchserviceinstance#sthash.d9rBKjLc.dpuf

Insufficient SQL database permissions for user '' in database '' on SQL Server instance ''. Additional error information from SQL Server is included below.

Event Type:    Error
Event Source:    Windows SharePoint Services 3
Event Category:    Database
Event ID:    5214
Date:        2/12/2013
Time:        2:51:05 PM
User:        N/A
Computer:    SERVERNAME
Description:
Insufficient SQL database permissions for user '' in database 'SharePoint_ConfigDBXX' on SQL Server instance 'SERVERNAME'. Additional error information from SQL Server is included below.

The EXECUTE permission was denied on the object 'proc_getNewObjects', database 'SharePoint_ConfigDBXX', schema 'dbo'.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

----


The procedure to solve the problem follow these steps:

    Open the SQL Management Studio
    Locate the database that presents the problem in my case was 'SharePoint_Config'
    Open the database and then Security> Roles> Database Roles
    In the right part of the window, right-click the role WSS_Content_Application_Pools and click on properties
    Select from the left menu option "Securables"
    By clicking "Add"
    Select "Specific objects" and click "OK"
    Click "Object Types", select "Stored Procedures" and click "OK"
    Add the stored procedures in the error in my case was the proc_GetNewObjects but it is also important to check whether the following stored procedures are added; proc_FetchDocForUpdate, proc_GetWebMetaInfo, proc_UpdateDirtyDocument, proc_UpdateListItem not I be there to add.
    Click Ok to add these stored procedures
    Teams stored procedures that were added and select "Execute" in the column of "Grant"
    Click "Add" once again
    Select "Specific objects" and click "OK"
    Click "Object Types", select "views" and click "OK"
    Check if the view is added UserData otherwise select to add
    Click on ok to add this view
    Teams eye that was added and select "Select" column of "Grant"
    Click on ok to finish.

Once this procedure done mistakes of 5214 should no longer appear in the event viewer of the server.

ref: http://mundomoss.blogspot.com.au/2010/04/sharepoint-error-5214-execute.html

Tuesday, November 26, 2013

Design Manager feature in SharePoint 2013



Design Manager is a feature in SharePoint 2013, which will make designer job easier to create a fully customized design while using the web-design tools that we're already conversant with.

Design Manager is a publishing feature that is available in publishing sites in both SharePoint Server 2013 and Office 365. You can also use Design Manager to brand the public-facing website in Office 365. To enable the Design Manager for the SharePoint sites, go to site settings under the Site Collection Feature enable the SharePoint Server Publishing Infrastructure.




Than go to the Site Features section and activate the SharePoint Server Publishing feature.



After activating the features, when click on the Site Settings menu you can the Design Manager has been enable for the designer. Please refer the following screen capture.



With the help of Design Manager, you can create a visual design for your website by using whatever web design tool design prefer, using only HTML and CSS, and then upload that design into SharePoint. Design Manager is the central hub and interface where you manage all aspects of a custom design.



Google