Exporting and Re-deploying SQL Server 2008 Maintenance Plans

Challenge: There’s lots of chatter out there about working around various issues related to pulling an SSIS package out of an initial definition server and then reinstalling it on other servers.  For example:

INSERT statement conflicted with the FOREIGN KEY constraint "FK_sysmaintplan_log_subplan_id". The conflict occurred in database "msdb", table "dbo.sysmaintplan_subplans", column 'subplan_id'.

The following scripts are my effort to bundle all the steps into something that allows me to forget about the messy details.
For me this comes in handy for managing a standardized maintenance plan on many identical database instances... e.g. a bunch of replication subscribers.
Notes:

• Full blown BIDS/SSIS vs Maintenance Plan wizard - My needs were met by the basic Maintenance Plan facility under the “Management” node in SQL Server Management Studio (SSMS).  From what I understand, this supports a subset of the full SQL Server Integration Services (SSIS) functionality.  Therefore, there is a lot of chatter about mixing and matching the two, with care.  In my experience, once I had loaded my plan in BIDS (Business Intelligence Development Studio), attempted any modification and then tried to execute the corresponding DTSX back under Maintenance Plans, it was no longer compatible with that execution context and I simply didn’t try to decipher the errors any further.
• I found that it’s convenient to have a “staging” server with identical SQL Server instance and database to what you care to redeploy to… therefore the maintenance plan you export is largely ready to go as-is.
• One manual DTSX tweak that remains necessary is to delete the encrypted password node and add the password directly to the connection strings… I believe the encryption is tied to a machine based key and therefore isn’t portable but I could be wrong about that.
• I’m using SQL Server 2008 R2.  I’m assuming everything is 2008 “R1” compatible and could very well work on SQL Server 2005 but I haven’t tried it.

Here’s some working code.

• All these scripts depend on environment variables SQLCMDUSER & SQLCMDPASSWORD being defined
• export_dtsx.cmd – Batch file which pulls the maintenance plan out of SQL Server to a local .DTSX file
• upload_dtsx.ps1 – PowerShell script which uploads the specified .dtsx file to the specified server.  Most significantly, this logic handles pulling the pertinent GUID’s out of the dtsx XML which are required to create the corresponding scheduled job records.
• create_maint_plan_job.sql – upload_dtsx.ps1 execute this script to create the SQL Agent scheduled job corresponding to the maintenance plan… the current parameters establish an every night, midnight run.  To determine representative arguments for your own preferred schedule, simply schedule a dummy job and “Generate Script” for that via SSMS.

SQL Server – [SOLVED] “Unable to initialize SSL encryption because a valid certificate could not be found, and it is not possible to create a self-signed certificate."

Nutshell solution: Generate a self-signed certificate and plug it into SQL Server Configuration Manager > SQL Server Network Configuration > Protocols for {instance_name} > Properties > Certificate > Certificate

I read through dozens of folks wrestling with this issue and various suggested remedies (reinstalling, sysprep, etc) yet I found none addressing the certificate error directly in this way … so it seems worth getting this message out there.

Cause: For me, my SQL Server 2008 R2 (v10.50.1600.1) install went wonky (ran into some group policy brick walls) and somehow the default self-signed certificate must've gotten wiped out.

Interestingly, on other servers where the install ran without issue, this certificate entry is also blank… so that tells me we’re fortunate SQL Server is able to utilize this new one we throw in.

One straightforward way to generate self-signed certs is with "SelfSSL.exe" from the IIS 6.0 Resource Kit Tools. Here's example command line usage:
             SelfSSL /N:CN={database server name} /V:1999999

• If you're not familiar with certs, the name must match the name of the machine exactly, or it won’t show up in SQL Server Configuration Manager’s certificate drop down list!… this name should be the “FQDN” (Fully Qualified Domain Name)… typically the “Full Computer Name” as listed under Control Panel > System.
• The /v option is the #days the cert is valid for... through empirical study I believe 1999999 is the max allowed… that currently pushes expiration out to the year 7487, which will hopefully last ya ;)
• SelfSSL often spews “Error opening metabase: 0x80040154” … This would probably be bad news if you wanted to use this certificate for IIS SSL but apparently it’s not a factor for SQL Server SSL.
• One can examine the certificates that have been generated this way by launching mmc.exe, adding the Certificates snap in, selecting “Computer account” and looking at the “Personal” certificate store.

In a blatant attempt to cast a wide net on search hits , here’s a typical log that’ll be spewed along with the aforementioned error:
2012-02-10 09:57:09.07 Server      Initializing the FallBack certificate failed with error code: 1, state: 1, error number: -2146893802.
2012-02-10 09:57:09.08 Server      Unable to initialize SSL encryption because a valid certificate could not be found, and it is not possible to create a self-signed certificate.
2012-02-10 09:57:09.08 Server      Error: 17182, Severity: 16, State: 1.
2012-02-10 09:57:09.08 Server      TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or prope
rty.
2012-02-10 09:57:09.08 Server      Error: 17182, Severity: 16, State: 1.
2012-02-10 09:57:09.08 Server      TDSSNIClient initialization failed with error 0x80092004, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for
previous errors. Cannot find object or property.
2012-02-10 09:57:09.09 Server      Error: 17826, Severity: 18, State: 3.
2012-02-10 09:57:09.09 Server      Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately pr
eceding this one in the error log.
2012-02-10 09:57:09.09 Server      Error: 17120, Severity: 16, State: 1.
2012-02-10 09:57:09.09 Server      SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related proble
ms.