Friday, July 9, 2010
Could not create SSOSQL. Error Code: 0x80131700
Friday, April 16, 2010
Restoring SQL Server 2005 Suspect Database
ALTER DATABASE "DBname" SET EMERGENCY
DBCC checkdb('DBname')
ALTER DATABASE "DBname" SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('DBname', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE "DBname" SET MULTI_USER
Wednesday, February 10, 2010
The SSO service failed to start. After installing VS 2010
I've been running BizTalk 2009 on my Windows 7 machine, and after installing VS 2010 beta 2, the Enterprise Single Sign-On Service stopped working.
It failed with the following error:
Could not create SSOSQL. To fix the problem, reinstall SSO or try 'regasm SSOSQL.dll' from a Visual Studio command prompt.
Error Code: 0x80131700
The file is located at C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSQL.dll
Run Visual Studio Commmand prompt as Administrator and run 'regasm "C:\Program Files\Common Files\Enterprise Single Sign-On\SSOSQL.dll"'.
On 64 bit machines (windows 7, Vista, W2008 etc) you need to call regasm.exe utility explicitly from this folder:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\regasm.exe
Thursday, February 4, 2010
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered error with 64bit OS
If you're getting this error while trying to connect to Access 2007 or Excel 2007 via the Office 12 OleDB provider, you must first make sure you have the Office 2007 data providers installed.
Next, under x64 (64bit), the data providers will not work by default as they are 32-bit only (x86), even if the data providers download page doesn't say it. You have to explicitly compile for x86 instead of the default "Any CPU" platform:...
Friday, January 22, 2010
The description for Event ID ( 17137 ) in Source ( MSSQL$MICROSOFT##SSEE ) cannot be found
Right click the database and select Properties->Options.
See if Auto close is set to True. If it is true, set it to false.
Monday, January 4, 2010
No exact match was found domain users. Domain users
Change the Application Pool Identity for SharePoint Central Administration (SCA)
Repeat these steps on each server which hosts the SharePoint Central Administration web application. If the web front-end (WFE) and application (APP) server roles are served by separate machines, SCA should be enabled on one APP server (or more) and stopped and/or removed from the WFE servers. This allows control over access to the SCA. The SCA service account should not be the same as that used for the SharePoint application pool so even if one is compromised, the other remains secure.
- Open a command prompt.
- Run: stsadm -o updatefarmcredentials -userlogin domain\username -password password
- Be patient. This may take a few minutes to run.
- To restart the application pool, either open IIS and recycle the application pool, or open a command prompt and type iisreset -noforce
- Open SharePoint Central Administration in a browser to confirm that the change was successful.
The above steps create an Administration Application Pool Credential Deployment timer job. You can see this in the Timer Job Definitions page. The job is complete when it no longer appears in the list of definitions (refresh the browser, this isn't automatic).