May 6, 2009 at 8:21 am
I will be changing the registry setting MsxEncryptChannelOptions using SQL so that I can configure msx/tsx servers, some servers are clustered and most are named instances.
Does anyone know the advantages, the differences or of any documentation for the undocumented extended stored procedures xp_regwrite and xp_instance_regwrite?
Thanks
May 6, 2009 at 8:40 am
http://www.mssqlcity.com/FAQ/Devel/xp_regwrite.htm
No real reason that this is better than scripting this in VBScript. I guess it might be easier if you have connectivity to each SQL Server instance.
I have had MSX/TSX servers get flaky on me in the past w/ 2000 when I deployed jobs and had to edit them or had connectivity issues. Instead I would deploy the same job to each server. I think it's as easy to script those as it is to script this reg change and you can then alter schedules, set exceptions, etc. for each individual server.
May 6, 2009 at 8:52 am
Thanks for the reply.
I'd not used msx/tsx before and it's supposed to be improved on 2005 so I thought I'd give it a go, so far I've been running it for three target servers running maintenance plans that run the scripts I normally run in jobs so I can get round the not being able to run the distributed jobs on the master server problem, with maintenance plans it lets you, anyway, no problems so far and I'm just developing some packages to automatically roll out a DBA database to new servers and configure them at the same time as target servers, it works so far as I've got to.
I've seen that link before, I can't find anything that tells me the difference between the two xps, all examples use the same syntax, I'm beginning to think there is no difference, I know you can still use xp_instance_regwrite in 2008 so maybe I'll go for that.
If there are any other suggestions or advice on msx/tsx please let me know.
Thanks
Mark
May 6, 2009 at 9:01 am
I haven't used it in 2005, and it might work much better. Never know how much work was done there between versions.
I'd still recommend you script the jobs, deploy them to all servers. You can have each server run independently, and then roll up all it's info into one report, combine them on one server each day.
However if it works for you, good luck. I'd be curious to know how it works. Or if you're up for documenting your process, send me an article on how well this worked in 2005.
May 6, 2009 at 9:08 am
I usually use the job approach on each server but I've just started working at this company and they wanted a more centralized way of controlling the maintenance so it's a good learning curve but I will let you know how it goes and try and put something together to document it so other people can see what was done and how it works.
Thanks
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply