Anyone else have errors when checking out SSIS package from SourceSafe or TFS?

I get errors when I check out an SSIS package from source control (both Source Safe and TFS) relating to the connection objects where I was not the original developer who checked it in. Is there a solution to this other than altering the connection login\password for every connection object in the package before deploying?

Yes, I do have problems as well when updating CVS.

For SSIS the solution is to use configuration files for your connections and Security / Protection Level property set to "DontSaveSensitive".

For Reporting services and cubes I am still a bit confused.

For reports, As soon as I open them in BIDS, I immediately edit the shared data sources to retype in the account and password. If I do not do it and go to the data page, it will loose all stored procedures parameters :-(

For Cubes, I also revisit the data sources as soon as I open the cube. Not doing so will let you work on your cube and deploy it, however you will not be able to browse, aggregate or process it.

Philippe

|||

The critical item here is to not have the Package Protection Level Property set to Encrypt[Sensitive or All]WithUserKey. That uses the developer's Windows login to encrypt information in the package, so no other developer will be able to work with it very easily, unless they log in with the same Windows account.

As Phillippe said, a common workaround is using a ProtectionLevel of "DontSaveSensitive" and configurations, which also makes it easier to deploy the packages in multiple environments. You could also use "EncryptSensitiveWithPassword" which will mean you have to enter a password for the package before running it, but it will be able to store the passwords inside the package, rather than depending on configurations. The best choice depends on your scenario.

Any permittedHost email security change lately?

UPDATE.

I am now checking with our IT if the SMTP corporate server has the correct relay authorisation for the new server. I may have overlooked this issue.

Hello,

Om my previous report server, I had not set amy DefaulthostName nor PermittedHost.

This allowed us to create subscriptions that get sent to our business partners with a long ever changing lists of email addresses and domains.

All server are build 2175, they ahve the same rsreportserver.config setting for the email portion. Problem is that on 2 of the servers, the email with a domain other than our internal domain do not get sent with error "The email address of one or more recipients is not valid". It works on the third server.

I tested our SMPT server from another application and it does send emails to external domains so the problem is really on the server side.

It is vey important because subscriptions are managed by a few business analysts, they spend a lot of time creating lot of subscriptions and the domains change often.

I tried on the dev server to define cox.net as Permitted host and send myself a report to my private email, it also returned the error.

Any idea as where to look at? is ther a specific CDO setting to allow relay?

Thanks,

Philippe

<SendEmailToUserAlias>False</SendEmailToUserAlias>
<DefaultHostName></DefaultHostName>
<PermittedHosts></PermittedHosts>

ReportingServicesService!emailextension!4!01/27/2007-11:47:12:: Error sending mail, CDO error -2147220977, will not resend
ReportingServicesService!emailextension!4!01/27/2007-11:47:12:: Error sending email. System.Runtime.InteropServices.COMException (0x8004020F): The server rejected one or more recipient addresses. The server response was: 550 5.7.1 <me@.cox.net>... Relaying denied. IP name lookup failed [10.100.15.87]

at ReportingServicesCDOInterop.MessageClass.Send()
at Microsoft.ReportingServices.EmailDeliveryProvider.EmailProvider.Deliver(Notification notification)

Most likely it is a security issue. The settings in the configruation file only determine what can be put in the subscriptions. Have you set up the local SMTP service and delivered to a pickup directory? you can then turn on logging and see what is going on.|||

Hi,

Per our IT specialist, this new server was not in the corporate DNS.

An entry as been added for it and RELAY is now working fine.

Regards,

Philippe