Do I trust what my SMS agents are telling me?

This XML update that was originally released Oct 10th and then updated Oct
19th has got me .
I have roughly 600 SMS clients, 150 of which would be XP machines and 450
Windows 2000.
Right now I have a little over 400 SMS clients (a mix of XP and 2000)
requesting 924191 which SMS describes as a Security update for Windows (but
updates the XML parser and Core Services), and another 532 clients
requesting 925672, described as MSXML4.0 SP2 Security update.
Obviously, I've got a lot of clients requesting both (or requesting the same
update under two different names'). Is this simply because they have
multiple versions of these XML components on their machines, all of which
need updating? These updates aren't going to stomp on each other? Should I
be deploying both?
Advice for an SMS admin (not an XML guy) appreciated.
SMS 2003 SP1 on W2K3 SP1> Obviously, I've got a lot of clients requesting both (or requesting the
> same update under two different names').
The update released for MSXML3 was seperate from the update released for
MSXML4, even though the issue that each of these updates fixed was the same.

> Is this simply because they have multiple versions of these XML components
> on their machines, all of which need updating?
Yes

>These updates aren't going to stomp on each other? Should I be deploying
>both?
No they are not going to stomp on each other, yes, deploy both.
"Phil McNeill" <philmcneill@.NOSPAM4MEhydroottawa.com> wrote in message
news:uhwgP$G%23GHA.1224@.TK2MSFTNGP04.phx.gbl...
> This XML update that was originally released Oct 10th and then updated Oct
> 19th has got me .
> I have roughly 600 SMS clients, 150 of which would be XP machines and 450
> Windows 2000.
> Right now I have a little over 400 SMS clients (a mix of XP and 2000)
> requesting 924191 which SMS describes as a Security update for Windows
> (but updates the XML parser and Core Services), and another 532 clients
> requesting 925672, described as MSXML4.0 SP2 Security update.
> Obviously, I've got a lot of clients requesting both (or requesting the
> same update under two different names'). Is this simply because they
> have multiple versions of these XML components on their machines, all of
> which need updating? These updates aren't going to stomp on each other?
> Should I be deploying both?
> Advice for an SMS admin (not an XML guy) appreciated.
> SMS 2003 SP1 on W2K3 SP1
>
>|||Thanks for the reply Alex. I was fairly sure that was the case, but already
deployed to my test group prior to the Oct 19th update that added updates
for Windows 2000. I'll deploy the additional updates to that group and see
how it goes.
Thanks again,
Phil
"Alex Krawarik[MSFT]" <alexkr@.microsoft.com> wrote in message
news:eC2DC0I%23GHA.3456@.TK2MSFTNGP02.phx.gbl...
> The update released for MSXML3 was seperate from the update released for
> MSXML4, even though the issue that each of these updates fixed was the
> same.
>
> Yes
>
> No they are not going to stomp on each other, yes, deploy both.
>

Do I need stop Agents during primary Server power down?

Hi,
Does anyone can tell that our production primary site need perform server
power down, and I have the databases transactional replication with push
setup on primary site? The secondary site will run all the time. Before,
primary site perform the power down, do I need stop the Log Reader and
Distribution Agents? What if I am not stopping those agents?
Regards,
Chen
You will be fine. Transactional replication replicates transactionally. So
if you power off in the middle of something, when it starts up again, it
will pick up where it left off.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"Chen" <Chen@.discussions.microsoft.com> wrote in message
news:D91896AE-5BF7-47FA-A0D7-D4BFC0CAF422@.microsoft.com...
> Hi,
> Does anyone can tell that our production primary site need perform server
> power down, and I have the databases transactional replication with push
> setup on primary site? The secondary site will run all the time. Before,
> primary site perform the power down, do I need stop the Log Reader and
> Distribution Agents? What if I am not stopping those agents?
> Regards,
> Chen
>
sql

Distribution of MSDE to 5,000 end users - good idea or bad?

Our company has an application that we distribute to our agents for generating sales quotes and it currently runs against an Access database. There is some interest in changing to MSDE and we're just trying to solicit some feedback from people that either investigated this or have tried it.

Here is our application and end user profile:

The application is a relatively small VB application that is distributed to about 5,000 agents. The data is stored in two separate physical database files (with many tables in each). One database stores the user-created data like prospects and configured options, and the other database stores the configuration options and rating data. The configuration option and rating data changes quarterly which is handled today through a new download of the software which overwrites the Access database that contains just that data. The agents are independent and sell for many companies, not just ours, and they own and use their own computer equipment. I would say they are probably at or below average for technical experience for end users. The proposal is to convert the application to run against an MSDE database and to include and install a copy of MSDE as part of the application installation. We would probably distribute service packs along with the quarterly updates, but agents do not always install the updates or could stop selling for us at any time, so there is no guarantee that the updates will ever be applied.

Dramatic overhauls of the application are not being considered at this time, and the users frequently do quotes while on-site with clients and they do not always have access to the Internet. In effect, while a web-based model may seem ideal, we would definitely lose sales if the agents are not able to quote with an off-line source of data and application, and the project is only evaluating whether or not it is a good idea to convert the database from Access to MSDE.

Thanks in advance for your comments!
ChrisYou've already pointed out the biggest issues. Service pack updates are a must. Beyond that, I would think this kind of situation lends itself to Access. I would think unless you plan on upgrading all of these machines to .NET, that it would be best to stick with the most distributable option of Access and the VB App.|||Should you decide to move this to .NET then an option might also be to just use XML for your data storage. If the amount of data is not very large, then Access or MSDE might actually be overkill. Deployment of XML based data is pretty straightforward too.

Distribution database is growing large...

Hi!
A few days ago the number of replication commands grew up to ~6 000
000. A normal number used to be ~20 000. The replication agents are
working fine. The data on subscribers are valid. I suspect that the
history clean up agents don't remove old commands, although their
status shows successful completion.
What could be a workout for such situation?
Thanks.
P.S.: I am using Win 2003 Ent Server + MS SQL 2000 sp3 and only
transactional replication.
Do you have anonymous subscriptions? If so the commands and transactions
will remain there until the end of the retention period.
Also it could be that you merely issued transactions that affected a large
number of rows. However, if these commands have been replicated to all
subscribers the distribution clean up agent should purge them every 10
minutes.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"Roust_m" <roustam@.hotbox.ru> wrote in message
news:a388fd78.0412020529.372a7316@.posting.google.c om...
> Hi!
> A few days ago the number of replication commands grew up to ~6 000
> 000. A normal number used to be ~20 000. The replication agents are
> working fine. The data on subscribers are valid. I suspect that the
> history clean up agents don't remove old commands, although their
> status shows successful completion.
> What could be a workout for such situation?
> Thanks.
> P.S.: I am using Win 2003 Ent Server + MS SQL 2000 sp3 and only
> transactional replication.

distribution cleanup cannot clean up snapshot folder

We are using SQL Server 2005 SP2 to do transactional replication.

We and have a separate service account for the SQL Agents (sqladmin) vs. SQL Replication Agents (sqlrepadmin). It is my understanding this is a replication security best practice. The sqlrepadmin has full permissions on the snapshot share folder and it's subdirectories. The sqladmin account does not have permissions at all.

I have been getting an error message when we run the distribution clean up job.

Executed as user: PROD\sqladmin. Could not remove directory '\\Tes01box\Repldata\unc\qabox01_DB01_TO_ORACLE\20070905104896\'. Check the security context of xp_cmdshell

I have dropped the publication and recreated which is what appears to have caused the error.

From

http://technet.microsoft.com/en-us/library/ms151151.aspx

Note:

If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. If this account does not have sufficient privileges, log in with an account that does have sufficient privileges and remove the folder manually. Removing a folder requires the Modify privilege if the folder is a local path or the Full Control privilege if the folder is a network path.

The note above implies that the SQL Server service account (sqladmin) needs permissions on the snapshot folder as well.

Finally my questions:

Is there a workaround that will allow the distribution cleanup job to run as sqlrepadmin and perform the delete?

If both sqlrepadmin and sqladmin need permissions to the snapshot what is the reasoning from a security perspective of separating them out?

open up your distribution clean up task job, and in the job step properties do the following:

setuser 'sqlrepadmin'
GO
EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0, @.max_distretention = 72
GO|||

I did have to qualify the domain, as in DOMAIN\sqlrepadmin to get it to work. We have same login for 2 different domains.

What an amazingly simple and elegant solution. I feel silly that I did not think of this.

Thank you Hilary.

distribution cleanup cannot clean up snapshot folder

We are using SQL Server 2005 SP2 to do transactional replication.

We and have a separate service account for the SQL Agents (sqladmin) vs. SQL Replication Agents (sqlrepadmin). It is my understanding this is a replication security best practice. The sqlrepadmin has full permissions on the snapshot share folder and it's subdirectories. The sqladmin account does not have permissions at all.

I have been getting an error message when we run the distribution clean up job.

Executed as user: PROD\sqladmin. Could not remove directory '\\Tes01box\Repldata\unc\qabox01_DB01_TO_ORACLE\20070905104896\'. Check the security context of xp_cmdshell

I have dropped the publication and recreated which is what appears to have caused the error.

From

http://technet.microsoft.com/en-us/library/ms151151.aspx

Note:

If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. If this account does not have sufficient privileges, log in with an account that does have sufficient privileges and remove the folder manually. Removing a folder requires the Modify privilege if the folder is a local path or the Full Control privilege if the folder is a network path.

The note above implies that the SQL Server service account (sqladmin) needs permissions on the snapshot folder as well.

Finally my questions:

Is there a workaround that will allow the distribution cleanup job to run as sqlrepadmin and perform the delete?

If both sqlrepadmin and sqladmin need permissions to the snapshot what is the reasoning from a security perspective of separating them out?

open up your distribution clean up task job, and in the job step properties do the following:

setuser 'sqlrepadmin'
GO
EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0, @.max_distretention = 72
GO|||

I did have to qualify the domain, as in DOMAIN\sqlrepadmin to get it to work. We have same login for 2 different domains.

What an amazingly simple and elegant solution. I feel silly that I did not think of this.

Thank you Hilary.

Distribution Agent TimeOut

I have setup pull transactional replication with multiple publications and
distribution agents.
One of my distribution agent always says the following error--
Timeout expired
(Source: ODBC SQL Server Driver (ODBC); Error number: S1T00)
while other agents are executed just fine..
any suggestions..?
Regards,
bump up LoginTimeout and QueryTimeout to 120.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"SQL Replication Guy" <SQLReplicationGuy@.discussions.microsoft.com> wrote in
message news:65DC7C0C-6149-4DB0-8C28-06DAC9EAAA59@.microsoft.com...
> I have setup pull transactional replication with multiple publications and
> distribution agents.
> One of my distribution agent always says the following error--
> --
> Timeout expired
> (Source: ODBC SQL Server Driver (ODBC); Error number: S1T00)
> --
> while other agents are executed just fine..
> any suggestions..?
> Regards,