|
|
Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
I have very little experience configuring servers so I'm not sure about how
to install Replication Manager on a server and make sure that the
synchronizer continues to run at all times. Unfortunately, I don't have
access to a server on which to experiment and I don't want to have to
experiment on a production server.
The server I need to install my replica set and Replication Manager on is in
a small facility which only has a couple dozen workstations and one server.
It's a stand alone LAN that several remote users connect to via a VPN. The
old server was just replaced with a brand new Windows 2003 box. That's all I
know about it as of now but I'll be meeting with the contracted network
admin who maintains the server soon. Could someone please explain to me in
the simplest possible terminology, how I should instruct a network admin to
install Replication Manager on a facility's server and make sure that the
synchronizer continues to run 24/7?
|
|
"Tom Stoddard" <tstoddard[ at ]andrewspaper.com> wrote in
news:#GaWGP0NGHA.1180[ at ]TK2MSFTNGP09.phx.gbl:
[Quoted Text] > I have very little experience configuring servers so I'm not sure
> about how to install Replication Manager on a server and make sure
> that the synchronizer continues to run at all times.
> Unfortunately, I don't have access to a server on which to
> experiment and I don't want to have to experiment on a production
> server.
There is no good way to do it. The Jet Synchronizer cannot run as a
system service and must run in a console logon. It can't be run in a
terminal server session, so far as I can tell -- it has to be a real
console logon. The only solution that works is logging on, starting
it up and locking the workstation. Whenever I've had the
synchronizer running on a production server, I've created a user
account specifically for that purpose and for none other that has no
permission to do anything at all except read and write to/from the
dropboxes and the folder where Replication Manager is installed.
> The server I need to install my replica set and Replication
> Manager on is in a small facility which only has a couple dozen
> workstations and one server. It's a stand alone LAN that several
> remote users connect to via a VPN. The old server was just
> replaced with a brand new Windows 2003 box. That's all I know
> about it as of now but I'll be meeting with the contracted network
> admin who maintains the server soon. Could someone please explain
> to me in the simplest possible terminology, how I should instruct
> a network admin to install Replication Manager on a facility's
> server and make sure that the synchronizer continues to run 24/7?
See above.
No Windows server admin who is worth his or her salt is going to
like doing this -- it's a very bad thing to do.
But Microsoft refused to make the synchronizer into a system
service.
You can try running it with SrvAny, the Windows Resource Kit utility
that allows you to launch any executable as a service, but you'll
find (as all of us who've tried it have found) that it will run, but
won't synch.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
[Quoted Text] > There is no good way to do it. The Jet Synchronizer cannot run as a
> system service and must run in a console logon. It can't be run in a
> terminal server session, so far as I can tell -- it has to be a real
> console logon. The only solution that works is logging on, starting
> it up and locking the workstation. Whenever I've had the
> synchronizer running on a production server, I've created a user
> account specifically for that purpose and for none other that has no
> permission to do anything at all except read and write to/from the
> dropboxes and the folder where Replication Manager is installed.
>
> See above.
>
> No Windows server admin who is worth his or her salt is going to
> like doing this -- it's a very bad thing to do.
>
What do you mean by locking and what are the objections to having a console
logon running and locking the workstation?
David, thanks for the advice, it's very helpful. If the admin doesn't want
to do this for me I need to have an alternate strategy in place. The way I
see it, I have very few options. One would be just to use a workstation on
the network and either leave it running overnight or just limit the hours in
which remote users can synchronize. If I set up Replication manager on a
workstation and have it manage replicas that are on the server (as in a
replica farm), will I be asking for trouble?
Do you have any other suggestions?
|
|
"Tom Stoddard" <tstoddard[ at ]andrewspaper.com> wrote in
news:#MoYNG8NGHA.1832[ at ]TK2MSFTNGP11.phx.gbl:
[Quoted Text] >
>> There is no good way to do it. The Jet Synchronizer cannot run as
>> a system service and must run in a console logon. It can't be run
>> in a terminal server session, so far as I can tell -- it has to
>> be a real console logon. The only solution that works is logging
>> on, starting it up and locking the workstation. Whenever I've had
>> the synchronizer running on a production server, I've created a
>> user account specifically for that purpose and for none other
>> that has no permission to do anything at all except read and
>> write to/from the dropboxes and the folder where Replication
>> Manager is installed.
>>
>> See above.
>>
>> No Windows server admin who is worth his or her salt is going to
>> like doing this -- it's a very bad thing to do.
>>
>
> What do you mean by locking and what are the objections to having
> a console logon running and locking the workstation?
If you hit Ctrl-Alt-Delete while logged on, one of the choices is
LOCK WORKSTATION. This is like a log off.
On WinXP, you'd just do SWITCH USERS and leave it running.
But on Win2K or Win2K3 server, that's not available -- you have to
lock the workstation.
The objection is that you've got a piece of software always running
in a logged-on session, which is potentially hackable. Secondly,
it's a piece of software running that wasn't really designed to run
on a server (if it was, it would be runnable as a system service),
and that should make any administrator somewhat nervous.
> David, thanks for the advice, it's very helpful. If the admin
> doesn't want to do this for me I need to have an alternate
> strategy in place. The way I see it, I have very few options. One
> would be just to use a workstation on the network and either leave
> it running overnight or just limit the hours in which remote users
> can synchronize. If I set up Replication manager on a workstation
> and have it manage replicas that are on the server (as in a
> replica farm), will I be asking for trouble?
The only option if the admin prohibits running it on the server is
to use a workstation. But, again, it has to be running at all times.
That's the advantage of running it on a server, that it's always on.
You might try to see if it can be run and used from a Remote Desktop
session. I can't remember where I got the idea that it could not.
That would allow you to initiate it remotely during certain time
periods, though I don't think there's any way to automate that.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|