Advertisements
Feeds:
Posts
Comments

Archive for the ‘Sharepoint’ Category


 

SharePoint

Error after configuration Wizard

I am having the following after installing the Central admin

 

Loading this assembly would produce a different grant set from other instances

I changed the following key as I found it in the following link

https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.TEC1445538.html

Configure the following registry settings using regedit.exe:

Solution

Change assembly load optimization

In key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework‘, create a new ‘DWORD (32-bit) Value’ named “LoaderOptimization” with a value 1 (either in decimal or hexadecimal as they are the same).

 

 

And here also

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework‘, create a new ‘DWORD (32-bit) Value’ named “LoaderOptimization” with a value 1 (either in decimal or hexadecimal as they are the same).

 

 

Note: restart the server

Now it’s working with me

Advertisements

Read Full Post »

EventID: 8319


 

EventID: 8319

This is the error and this is the EVENT NAME

Table SqlIoData_Partition27 has 443957248 bytes that has exceeded the max bytes 442857142

Which is the SQL IO Usage event

To know the database name

Go to central admin

First, we must get the database name

 

The database name is

WSS_Logging

 

 Now we need to find which table is taking most of the space inside the WSS logging Database.

You can check from the SQL Server

Login to SQL Server Management Studio -> Select your logging Database (Right Click) -> Reports- > Standard Reports -> Disk Usage by Top Tables

The SQL IO Usage event

We can reduce the retention period of any events (default is 14)

Table SqlIoData_Partition27 has 443957248 bytes that has exceeded the max bytes 442857142

 

In my case its SQL IO

Any way if we couldn’t know exactly which identity is causing the problem we can just

Set them all to any number of days

Then log in the SharePoint power shell

Get-SPUsageDefinition

Set-SPUsageDefinition –Identity “Page Requests” -DaysRetained 3

Now I just changed the page Request to 3 days

Alternatively, you can set all the Identities once

By the following command

Get-SPUsageDefinition | Set-SPUsageDefinition -DaysRetained 3

After you are done

Run the two-timer jobs to clean the old data ‘Microsoft SharePoint Foundation Usage Data Import’ and ‘Microsoft SharePoint Foundation Usage Data Processing’.

Go to SharePoint Central Administration -> Monitoring -> Configure Usage and health data collection-> Log Collection Schedule.

Moreover, it will take you to the timer jobs.

 

Read Full Post »

EventID: 8319


 

EventID: 8319

This is the error and this is the EVENT NAME

Table SqlIoData_Partition27 has 443957248 bytes that has exceeded the max bytes 442857142

Which is the SQL IO Usage event

To know the database name

Go to central admin

First, we must get the database name

 

The database name is

WSS_Logging

 

 Now we need to find which table is taking most of the space inside the WSS logging Database.

You can check from the SQL Server

Login to SQL Server Management Studio -> Select your logging Database (Right Click) -> Reports- > Standard Reports -> Disk Usage by Top Tables

The SQL IO Usage event

We can reduce the retention period of any events (default is 14)

Table SqlIoData_Partition27 has 443957248 bytes that has exceeded the max bytes 442857142

 

In my case its SQL IO

Any way if we couldn’t know exactly which identity is causing the problem we can just

Set them all to any number of days

Then log in the SharePoint power shell

Get-SPUsageDefinition

Set-SPUsageDefinition –Identity “Page Requests” -DaysRetained 3

Now I just changed the page Request to 3 days

Alternatively, you can set all the Identities once

By the following command

Get-SPUsageDefinition | Set-SPUsageDefinition -DaysRetained 3

After you are done

Run the two timer jobs to clean the old data ‘Microsoft SharePoint Foundation Usage Data Import’ and ‘Microsoft SharePoint Foundation Usage Data Processing’.

Go to Sharepoint Central Administration -> Monitoring -> Configure Usage and health data collection-> Log Collection Schedule.

And it will take you to the timer jobs.

 

Read Full Post »


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

Event ID 6482

When I view the event logs on the Web Server I see several errors with the Event ID 6482:


Locate the following GUID


ba0cdef8-dc42-4b2c-8d91-ce1586e1d8e4

 Managed to fix this error by following these steps:

  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
    1. C:\ProgramData\Microsoft\SharePoint\Config
    2. In my case it will be
    3. C:\ProgramData\Microsoft\SharePoint\Config\925cd5c7-994f-438a-a5da-a8c179e0e85e\ba0cdef8-dc42-4b2c-8d91-ce1586e1d8e4.xml

      So I will delete all XML under the (C:\ProgramData\Microsoft\SharePoint\Config\925cd5c7-994f-438a-a5da-a8c179e0e85e )folder

      Note: never delete the .ini File


  3. Locate the GUID 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)


  1. Back up the Cache.ini file (and the other xml files)
  2. 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.
  3. Double-click the Cache.ini file
  4. 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.
  5. 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.

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.

 

Ref:

http://sharepoint.stackexchange.com/questions/125263/application-server-administration-job-failed-for-service-instance-microsoft-offi

Read Full Post »


Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [UserPrincipalName username@Domain.com;]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.

First run the LDP tool

https://support.microsoft.com/en-us/kb/2641663

then

  • Connect to Office 365 by using the Azure Active Directory Module for Windows PowerShell. To do this, follow these steps:

  • Click Start, click All Programs, click Windows Azure Active Directory, and then click Windows Azure Active Directory Module for Windows PowerShell.

  • Type the following commands in the order in which they are presented, and press Enter after each command:

    $cred = get-credential

    Note When you are prompted, enter your Office 365 administrator credentials.

    Connect-MSOLService –credential $cred

    Leave the console window open. You will have to use it in the next step.

  • Check for the duplicate userPrincipalName attributes in Office 365. In the console connection that you opened in step 2, type the following commands in the order in which they are presented, and press Enter after each command:

    $userUPN = “<search UPN>”

    Note In this command, the placeholder“<search UPN>” represents the UserPrincipalName attribute that you recorded in step 1f.

    get-MSOLUser –UserPrincipalName $userUPN | where {$_.LastDirSyncTime -eq $null}

    Leave the console window open. You will use it again in the next step.

  • Check for duplicate proxyAddresses attributes. In the console connection that you opened in step 2, type the following commands in the order in which they are presented, and press Enter after each command:

     

     

    $SessionExO = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Cred -Authentication Basic –AllowRedirection

     

     

    For each proxy address entry that you recorded in step 1f, type the following commands in the order in which they are presented, and press Enter after each command:

    $proxyAddress = “<search proxyAddress>”

    Ref:https://support.microsoft.com/en-us/kb/2641663

Read Full Post »

%d bloggers like this: