Security plugin error: An error has occurred in the plugin, but the plugin is unable to return a detailed error message.

I'd been told that fixing this issue required a service pack to the Crystal Designer installation, but it was over 200MB and before I rolled it out, I decided to do a bit of searching. It turns out that this error is caused by a pair of missing DLL files on the local machine:

smcommonutil.dll
smerrlog.dll

You can get these files from your Business Objects Enterprise CMS servers, since they have the full install already, from either of these locations:

(Install Drive):\Program Files\Business Objects\BusinessObjects Enterprise 12.0\win32_x86\
(System Drive):\Windows\System32 (SysWow64 if you've installed it on an x64 system)

Grab those two files and copy them to the C:\Windows\System32 folder on your local workstation and you'll be good to go - now Crystal Designer connects to the BOE CMS without any complaints at all.

Thanks to this forum post for pointing me in the right direction!

CREATE FILE encountered operating system error 5 (Access is denied.)
while attempting to open or create the physical file
'X:\MSSQL10_50.INSTANCENAME\TempDB\tempdb.mdf

The error means that SQL Server doesn't have NTFS rights to the location of the TempDB, but when I tried to add those rights, the permissions weren't granted to the domain proxy account as I'd expected, but were instead granted to the service SID account, MSSQL$InstanceName. I attempted to grant the permissions to this account at the new location, but couldn't get it to resolve to an actual account. What finally worked was:

1. In the permissions change dialog box, change the "Location" from the domain to the local machine (even though it's a cluster and your using a domain account to run the service)
2. In the text box, type "NT Service\MSSQL$INSTANCENAME" and click "Check Names"

Even though that appears to be a local account, it will resolve properly on all the cluster nodes involved. This step, as opposed to using the domain proxy account the service is running as, was necessary because (during the initial SQL Server setup process) I'd selected to use the proxy account SID to host permissions rather than a domain group. The better choice permissions-wise, but the source of some confusion!

If you installed it from an MSI:
x64 - C:\Program Files (x86)\Microsoft File Transfer Manager\TransferMgr.exe
x86 - C:\Program Files\Microsoft File Transfer Manager\TransferMgr.exe

Downloaded automatically in IE (more likely):
%SystemRoot%\Downloaded Program Files\TransferMgr.exe

Mine was hiding in that second location - if you download it directly in IE, it doesn't create a start menu icon, so you're not able to re-launch the tool unless you know the file location.

Exception message: An attempt was made to access a socket in a way forbidden by its access permissions
Stack Trace:
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at System.Net.Sockets.TcpListener.Start(Int32 backlog)
   at System.Runtime.Remoting.Channels.ExclusiveTcpListener.Start(Boolean exclusiveAddressUse)
   at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel.StartListening(Object data)
   at System.Runtime.Remoting.Channels.Tcp.TcpServerChannel..ctor(IDictionary properties, IServerChannelSinkProvider sinkProvider, IAuthorizeRemotingConnection authorizeCallback)

Though Googling gave some suggestions to run the process as an administrator (no effect), the actual problem was that my process was trying to listen on a port that was already taken by another listener. Since the port was already in use, it couldn't bind and I received the exception. Stopping the other process resolved the issue immediately.

Not really a clear error message, since it really had nothing to do with permissions at all, but there you go.

http://dbperf.wordpress.com/2010/07/10/walkthrough-cluster-setup-sql-win-2008/

After some digging, we discovered that it happened when the source server was Windows Server 2008 (or 2008 R2), regardless of what OS the remote linked server was running, and the issue wasn't tied to any particular version of SQL Server. As it turns out, it related to everybody's least favorite network setting, TCP Auto-Tuning - disabling it on the affected source servers resolved the problem immediately, and the queries returned instantly again.

To remedy the situation, follow these steps:

1. On the source SQL Server (the one executing the query, not the linked server), open an elevated command prompt (Right click on CMD.EXE and click "Run as Administrator")
2. To disable TCP Auto-tuning, run the following command:

   netsh int tcp set global autotuninglevel=disabled

3. To disable Windows Scaling Heuristics (another feature that can speed up clients, but is no good for servers), run:

   netsh int tcp set heuristics disabled

4. This will automatically take effect after Windows has the chance to refresh some network communications - you can either wait about an hour, or, if you'd prefer it take effect immediately, restart the SQL Instance. A reboot isn't necessary for this setting to take effect.

I'm not sure why these settings are on by default for servers - they seem to speed up internet browsing and other client-type activities (though there's no shortage of complaints online about them grinding Windows Vista/7 clients to a halt as well), but can cause big problems on servers.

In IIS 6 (Windows XP/2003), type:

iisapp

It is located in C:\Windows\System32 which is almost always part of the PATH variable so you can run the command from anywhere (like iisreset).

In IIS 7/7.5 (Windows Vista/7/2008/2008R2):

appcmd list wp

It is in C:\Windows\System32\Inetsrv\ which is not in the PATH variable by default so you can switch to that folder first and run the command.

If you're running multiple app pools on the server with the same proxy user account, now you can tell which one owns the application you're trying to debug!

All I wanted was a simple process that would run automatically, taking periodic snapshots of the database objects and recording any changes. I decided to roll my own - it's quick, simple, can be set up to run on a schedule, and automatically includes any new databases created on the server without any intervention.

This Stored Procedure goes through the following steps:

1. If the Master.dbo.coSourceControl table (used to store the history) doesn't exist, it creates it
2. For each database on the server (so new databases are added automatically), it:
   1. Grabs the text contents of all the user objects (not flagged as "IsMsShipped")
   2. Compares the contents of each to the last known copy (if there is one)
   3. If the object is new or has changed, add a new copy to the source control table in master
3. Output the number of objects updated
4. Optionally, it could email somebody to tell them about the results, but it currently does not

The history is kept in a single table - master.dbo.coSourceControl - which has the database it came from, the object_id, the object name, object contents, and the timestamp. Since it uses the object_id to track things, it will also record a name change in an object, even if the contents didn't change.

To implement it, just grab the script and run it in the master database - it will create the stored procedure coSourceControlRefresh. That's it - now either run it on demand, or you can schedule it. It will create the supporting table (if it's missing) and scan every database every time it's run. To see the history for an object, just do:

  SELECT db_name(databaseid) as [Database],
         object_name(objectid) as [Object Name],
         SourceDate,
         ObjectText
    FROM master.dbo.coSourceControl
   WHERE object_name(objectid) LIKE '%The name of some object%'
ORDER BY SourceDate DESC

Restoring a dropped or changed database object should be as simple as running the query above, grabbing the contents of ObjectText you're interested in, and then pasting it in another window and executing it. Bam - previous version of the object restored (and this stored proc should, the next time it runs, see that you've altered the object and record that there's a "new" version of it).

If you run it and like it - or don't like it - please leave a comment to let me know - nothing expected in return, but it's nice to know when people find it useful. I'm happy to make any enhancements you'd like to see. I hope you enjoy it and it's able to save you from the headache of a dropped database object to which you can't find the source!

Download the Source Control database script

1. First, download and install OpenSSL from Shining Light. The "Light" version of the package will do, since you're only using basic functionality.
2. Generate your Certificate request (CSR), specifying an SHA256 signature hash

   1. openssl req -nodes -sha256 -newkey rsa:2048 -keyout C:\SomeFolder\PrivateKey.key -out C:\SomeFolder\CertificateRequest.csr

   2. You'll be prompted for a few certificate fields, including your state, company name, computer name on your certificate, etc. Enter these as they come up.
3. This will generate two files - PrivateKey.key (which contains the un-encrypted version of your private key - protect this file, as somebody who obtains it along with your signed public key can impersonate you), and CertificateRequest.csr (your certificate signing request, which is not sensative).
4. Though this isn't required, if you want to confirm what you're entered in the CSR, you can view the details using another OpenSSL command line

   1. openssl req -in C:\SomeFolder\CertificateRequest.csr -text -noout

5. Now that you have your CSR, submit it to whatever signing authority you use - for us, it was Verisign, but there are any number of different CAs out there that can sign it.
6. Once your CA has signed the CSR, you'll get back either a binary p7b file (which we'll called SignedKeyFromCA.p7b) containing your certificate signed public key (and, possibly, the certificate chain your CA used as well), or either a binary or base64 CER file containing just your certificate. Whatever you receive back, you'll need to convert it to a Base64 CER (called SignedKeyFromCA.cer here), since that's what OpenSSL expects.
7. To combine your private key with the signed public key to create a certificate:

   1. openssl pkcs12 -export -in c:\Temp\SignedKeyFromCA.cer -inkey c:\temp\openssl.key -out SignedKeyPair.p12

   2. Since you're exporting your private key in this file, you'll be required to encrypt it with a password, which OpenSSL will prompt you for (twice).
8. You've now got your signed key pair - SignedKeyPair.p12. You can either use this pkcs12 file in your code, or you can import in into your web server (assuming it supports SHA256 hashes). IIS7, for example, supports importing this certificate and using it for SSL, but just doesn't support generating a SHA2 CSR in the first place.

Enjoy! If you have any issues, please feel free to post a comment and I'll do my best to answer it!

Warning Message: [2011-05-12 20:12:14Z] Servicing step Register Integration Database failed. (ServicingOperation: UpgradePreTfs2010Databases; Step group: AttachPreTFS2010Databases.TfsFramework)
Warning Message: TF255271: The team project collection could not be created. The number of steps before the completion of project creation is: 216. The number of steps completed before the failure was 10.

The error message doesn't give any detail at all, so I opened the log file and found this near the bottom:

[Info   @20:12:19.133] [2011-05-12 20:12:14Z][Error] BisCreateSchema.sql Line 816 Error: Incorrect syntax near ','. (10 of 216)
[Info   @20:12:19.133] [2011-05-12 20:12:14Z][Informational] Microsoft.TeamFoundation.Framework.Server.CollectionServicingException: BisCreateSchema.sql Line 816 Error: Incorrect syntax near ','.
---> System.Data.SqlClient.SqlException: Incorrect syntax near ','.

Try as I might, I couldn't find the SQL file it referred to, and Google wasn't much help either - however, it seemed that the SQL file wasn't actually to blame, especially since the same upgrade process had run flawlessly on my test server a few days earlier. Then I realized that my test server was SQL 2008 and my production server was SQL 2005 - while I didn't read specifically anywhere that this was a problem, SQL 2005 isn't supported by TFS 2010.

After much digging, the cause of the error ends up being that the TFS upgrade tool (and TFS 2010 in general) doesn't support SQL Server 2005. Upgrading the database server to SQL Server 2008 and re-running the process corrected the error and allowed us to complete the migration.

However, I've read that SQL 2008 support on TFS 2005 is patchy, so this also obliterates your rollback, if you were planning on one If you get this error, hope this helps!