November 24, 2014 at 5:59 am
Hi all,
OK so let me try and explain my issue as its a bit confusing.
We recently migrated from a clustered instance to a singel stand alone instance. We restored the MSDB in single user mode and then all the usual stuff like scripting out users and hashed passwords, restoring user databases and linking orphaned users etc.
All seems well so far, but when ive come to setup database email im getting weird things happening.
I have a job set-up to email a shared mailbox and myself when a job failure occurs, The job is running and completing successfully but the shared mailbox is receiving a failed email! Even stranger the email it receives is from the new server and contains the old email body (i updated it after migration to include the new server name)
So i'm thinking somewhere in the migration there is still a copy of the old job running (the old instance has had its jobs disabled) but i cannot see any in SSMS or SSIS?
Any ideas?
November 24, 2014 at 7:01 am
Are you looking at the agent job history to work out if the job completed successfully, because it may confirm that its completed successfully if it was able to send out the failure notification. You might want to collapse the steps to ensure all steps completed successfully.
In terms of the message in the email body, you need to update the email step in the maintenance plan or sql agent job step. Even though you have changed your email address you will still need to change the message in the maintenance plan/agent job.
Hope this helps.
--------------------------------------------
Laughing in the face of contention...
November 24, 2014 at 7:11 am
Sorry yes i have updated the email message (the address is the same)
The old (original) email just said
Transaction Log Backup Failed
But the new one says:
<servername>\<instance> - Hourly Log Backups Failed
Server: <servername>
November 25, 2014 at 3:14 pm
SSIS packages store the connection information in the package - and that is not stored as localhost. It is stored as the instance name - and for default instances will be stored as the server name.
Maintenance plans are SSIS packages - so those packages are actually running against your old server and not backing up your new servers databases.
The only way to fix this issue is to delete the maintenance plans and recreate them.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
November 25, 2014 at 4:10 pm
Even if we exported the SSIS package with Integration services and edited the XMl to point to the new server name?
Its weird because the new instance name is the same as the old one in everyway. We even have a CNAME entry in DNS so we can refer to it via its old clustered name so we didn't have to reconfigure every client application.
The connection on the new instance is still pointing to the correct name (in this case the CNAME in DNS)
Let me clarify. We moved from a clustered instance to a single instance. The old virtual network name for the instance was something like 'sqldb1vs1\instance' so we installed SQL on a new box and migrated everything across, we then renamed the old clustered instance network name to 'oldsqldb1vs1' and added a CNAME DNS entry to point 'sqldb1vs1' at the new server. This works fine and all client applications are now being directed to the new install. We exported the maintenance plans with integration services and made sure the connection string was still correct and imported them to the new instance. Backups work, just email is a little off. Its sending me the email from the old instance to 1 email address but when it sends to me i get the correct message (with the updated email body)
So to summarise the connection string is correct as backups are being made on the new instance. Just emails are confused.
November 26, 2014 at 1:07 am
Hi, for the email step have you updated the network connection? That might be forcing the connection to the old instance. You may also want to try and create the email step again and test it with the new config.
--------------------------------------------
Laughing in the face of contention...
November 26, 2014 at 1:42 am
Yep we updated the string although the server name is the same. including the CNAME pointing to the same virtual network name (as explained above)
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply