 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Replication / March 2006My plan to use replication: Good or Bad?
My wife has a business and I have developed a split Access 2003 database to keep track of things. At the business there is one desktop computer with WinXP Home Edition. She has dialup internet access. That's all that's available there. At home we have a peer to peer network with always on broadband connection. At home she uses a laptop with WinXP Home Edition. She would like to take a replica of the database with her to potential customers sites. At my business I have a Windows SBS 2003 Server with a static IP's and broadband. I do not have Replication Manager available in earlier developer editions of Office. My plan is to put the backend on my SBS 2003 server and make two replica backends to place on the desktop at my wifes work and her laptop. The frontends would work with the data in the replica backends. The idea is that the master backend would never have data entered directly. It is only used to sync. However often, the desktop at her business would connect to my SBS throught vpn and sync. She could do the same with her laptop from wherever she had internet access. Is this a reasonable plan? Is this the idea behind the replication feature of Access. Would I be able to move the master off the SBS server to another server if I wanted? Would I be able to automate the sync process at her work? I'd think that it would be good to have it dial up and sync at startup or when exiting or both? Would that be a very slow process to have to go through when starting the database? Lots of questions I know. Seems like a big decision. TIA Steve > My wife has a business and I have developed a split Access 2003 > database to keep track of things. At the business there is one [quoted text clipped - 4 lines] > connection. At home she uses a laptop with WinXP Home Edition. . . > . XP Home is a red flag for me. I'd never use it for anything at all, because the networking is crippled (limited to so-called "Simple File Sharing," which brings a whole hosts of problems in regard to security and customization). I don't know if indirect replication is even possible with Simple File Sharing -- I'm just not sure about it. > . . . She would like to take a > replica of the database with her to potential customers sites. At > my business I have a Windows SBS 2003 Server with a static IP's > and broadband. I do not have Replication Manager available in > earlier developer editions of Office. In this situation, with a Win2K3 server in the mix, I'd be contemplating whether or not I should skip replication and host the app on the server via Windows Terminal Server. SBS will not let you upgrade WTS beyond the built-in 2 administrative TS logons, but that would probably be sufficient for your wife's situation (though it does require using an administrative logon for connecting). There may be reasons why this is not possible (depending on always having an Internet connection to the TS may be an unreasonable condition), but in any situation where it *is* possible, I'd definitely prefer it, as it's much simpler to administer than any form of replication. > My plan is to put the backend on my SBS 2003 server and make two > replica backends to place on the desktop at my wifes work and her [quoted text clipped - 4 lines] > and sync. She could do the same with her laptop from wherever she > had internet access. This requires indirect replication. Theoretically, there's no need to have Replication Manager to do this, but practically, people have run into problems without it. > Is this a reasonable plan? Is this the idea behind the > replication feature of Access. . . . Pretty much. > . . . Would I be able to move the master off the SBS server to > another server if I wanted? Only using the MOVE REPLICA command (with ReplMan, the TSI Synchronizer, or JRO). Doing it without that would create a dead replica, which could cause major problems. > Would I be able to automate the sync process at her work? I'd > think that it would be good to have it dial up and sync at startup > or when exiting or both? Would that be a very slow process to > have to go through when starting the database? I would not make it a part of the startup process. My experience with indirect replication is that daily synchs generally take less than 10 minutes (over dialup), but it really depends on how much data has been changed. It seems to me that most of the time of an indirect synch is taken up with the housekeeping and not with the data transfer, as even when run broadband to broadband, it still takes 5-10 minutes to complete.  SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thanks David! I tried it a bit with a test database from a couple of computers including my wifes laptop. It seemed to work. I think maybe she should just spring for a decent internet connection at her work and follow your suggestion of hosting it on my server. So would I install Access right on the SBS 2003 box and let them have administrator accounts on the server so they can access the server using remote web access? Or is there some other TS client? I know this may be off topic but could you give me some more info on how to implement TS for Access on the SBS server? Or point me in the right direction. TS might even work with a dialup since all the stuff would be processed on the server? >> My wife has a business and I have developed a split Access 2003 >> database to keep track of things. At the business there is one [quoted text clipped - 69 lines] > and not with the data transfer, as even when run broadband to > broadband, it still takes 5-10 minutes to complete. > Thanks David! I tried it a bit with a test database from a couple > of computers including my wifes laptop. It seemed to work. I [quoted text clipped - 3 lines] > and let them have administrator accounts on the server so they can > access the server using remote web access? . . . It's not web access, but remote desktop. I think it's on by default in Win2K3 Server. You could try running the Remote Desktop client on a workstation and trying to connect to the server on the local network to see if it works. > . . . Or is there some > other TS client? I know this may be off topic but could you give > me some more info on how to implement TS for Access on the SBS > server? . . . The Terminal Server support should already by on, by default. Check it as I said above from the local network. > . . . Or point me > in the right direction. TS might even work with a dialup since > all the stuff would be processed on the server? Exactly. Terminal Server works pretty well over dialup, actually, because the Remote Desktop protocol sends the primitive graphics commands, rather than the bitmaps. This is substantially more efficient than any of the other remote control solutions. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi, Just food for thought, > It's not web access, but remote desktop. I think it's on by default > in Win2K3 Server. You could try running the Remote Desktop client on > a workstation and trying to connect to the server on the local > network to see if it works. I'm running W2K3 SBS and extensively use TS / Remote desktop to administer the server. And it is correct that TS is installed by default. However, I've always avoided running TS / Remote Desktop to run desktop applications such as Access, Word, etc ON the server. Heaven forbids a misbehaving app might bring down the server. I think there is a good reason why TS/Remote Desktop connections to Windows servers are limited to admin only, that is, to administer the servers (not to run apps). I would suggest setting up a remote desktop or Netmeeting connection to a workstation (as opposed to the server) with Access front end installed on the workstation and the back end on the server. Immanuel Sibero > > Thanks David! I tried it a bit with a test database from a couple > > of computers including my wifes laptop. It seemed to work. I [quoted text clipped - 25 lines] > commands, rather than the bitmaps. This is substantially more > efficient than any of the other remote control solutions. > Just food for thought, > [quoted text clipped - 11 lines] > connections to Windows servers are limited to admin only, that is, > to administer the servers (not to run apps). Er, they aren't limited to that. Only SBS limits them that way. On the other versions of Win2K3 Server (as well as Win2K Server), you can run as many sessions as your hardware and bandwidth support, and it's not really too much of a load, if you've got sufficient RAM. > I would suggest setting up a remote desktop or Netmeeting > connection to a workstation (as opposed to the server) with Access > front end installed on the workstation and the back end on the > server. This makes no sense to me. Windows Terminal Server (the technology that Remote Desktop is built on top of) is built into all server versions of Windows, with the very idea that you can run remote terminal sessions for users to use remote applications. I have clients running Access apps from remote locations in Terminal Server sessions, one client has a dedicated Terminal Server box for this (up to 10 simultaneous users), another supports a handful of users on the same box as their Exchange Server/file server. Both work just great. It's built into the OS. That is, Win2K Server and Win2K3 Server are *designed* to be usable in this fashion. There is nothing at all unsupported or dangerous about this -- it's the way it was *indended* to be used. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David, > Er, they aren't limited to that. Only SBS limits them that way. Your points are valid. I do agree that Terminal Services *are* designed to run desktop apps remotely. But we're talking about SBS Server which is what the OP uses? Would your recommendation be the same? MS limits the Terminal Services to 2 administrative logons on SBS servers. I take this to mean that MS only wants TS on SBS servers for server administration purposes only. From a network administration standpoint (which I wear that hat too), I'm not sure I would want any users running remote applications to have admin privileges. Now, if you put another Windows Server (W2K3) as TS in the mix, then that's a different story. But in the OP's case it's not necessary, therefore my recommendation to just remote desktop to a workstation. Immanuel Sibero > > Just food for thought, > > [quoted text clipped - 36 lines] > unsupported or dangerous about this -- it's the way it was > *indended* to be used. >> Er, they aren't limited to that. Only SBS limits them that way. > > Your points are valid. I do agree that Terminal Services *are* > designed to run desktop apps remotely. > But we're talking about SBS Server which is what the OP uses? > Would your recommendation be the same? Yes. It's binary-identical to the other versions. It's only packaging that makes it impossible to run other than the 2 admin TS sessions. > MS limits the Terminal Services to 2 administrative logons on SBS > servers. I take this to mean that MS only wants TS on SBS servers > for server administration purposes only. . . . No, they want you to spend more money buying a more expensive version of Windows Server, plus Exchange and SQL Server, instead of the bundled price that you get with SBS. That's why it's limited, because otherwise you could set up a TS on a cheap copy of Windows Server. > . . . From a network administration standpoint > (which I wear that hat too), I'm not sure I would want any users > running remote applications to have admin privileges. . . . This is a problem, yes. But the solution is not to have bought SBS. Unfortunately, that option is foreclosed. > . . . Now, if you put another > Windows Server (W2K3) as TS in the mix, then that's a different > story. But in the OP's case it's not necessary, therefore my > recommendation to just remote desktop to a workstation. That workstation can't be used by another person while someone is running a remote desktop session to it, but *two* people can run remote desktop sessions on the server while the server continues to serve all its other functions. I'm not certain, but I believe that an admin can also run a console logon at the same time. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thanks everyone. I'm still giving this some thought. I use remote desktop regularly to access desktops at work. I also use it to administer the server. These seem like good ideas. I understand the pros and cons of going either direction (rdp into workstation or server). At my wife's business she will only have a dialup. Mostly she would be looking up information in the database. Very little would be entered at that location. She doesn't like the idea of having to wait for a dialup connection to access her data. That's one of the reasons replication seemed like a good idea. That way she could update at her convenience i.e. the end of the day or week. She envisions having a customer standing there waiting for a receipt while the system dials up and makes a remote connection. I can see her point. The idea of having the master more or less permanently residing on a particular server is the part I'm concerned with. What if I get a new server and locate it somewhere else?Seems like it would be a pain to move, if that's even an option. Another drawback of using replication is; someday she will have a fast, always on internet connection at her business. She will want me to convert the database back. This seems like it could be very difficult? As with most things there are many trade offs. :) Thanks again! >>> Er, they aren't limited to that. Only SBS limits them that way. >> [quoted text clipped - 34 lines] > serve all its other functions. I'm not certain, but I believe that > an admin can also run a console logon at the same time. > The idea of having the master more or less permanently residing on > a particular server is the part I'm concerned with. . . . Well, by "master" if you mean the Design Master, that can be anywhere. It certainly shouldn't be used as a hub for regular synching or for daily editing. > . . . What if I get a new > server and locate it somewhere else?Seems like it would be a pain > to move, if that's even an option. . . . How are you going to move the data from the old server to the new? The easiest method is to have the two machines sitting side by side and transfer the data. If you then retire the old machine and give the new one exactly the same name (with the data locations exactly the same as the old server) then the replica on the server won't know it's on a different machine. Even if you don't do that, you can just recover the design master. You will have a dead replica, though, which may or may not be a problem in the future. > . . . Another drawback of using replication is; someday > she will have a fast, always on internet connection at her > business. She will want me to convert the database back. This > seems like it could be very difficult? If it ain't broke, don't fix it, I'd say. And I don't see any difficulty in stopping the synchronization. You'd just stop doing it. On the other hand, you might want to keep the replication for any laptop that travels. If it's not possible to go with always-on broadband now, then I'd just go with the replication and not worry about the future. It will be a lot less work to move to a Terminal Server-based scenario than it will have been to set up indirect replication. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thanks David. Earlier in this thread you said, "This requires indirect replication. Theoretically, there's no need to have Replication Manager to do this, but practically, people have run into problems without it." Coul you explain how to do it without Replication Manager or point me to some resources. I have read question number 17 in the FAQ document (ReplFAQ2K.doc) on Microsofts site regarding indirect synchronization. It of course talks about Replication Manager. I'm using Access 2003 with no hope of getting Replication Manager. I have setup a test synchronizing from a replica on the computer at my wife's business using dialup to a design master on my SBS server. I simply open her replica and tell it to synchronize with the design master on my SBS server. It's slow but seemed to work. I'm sure it's not advisable, but is that how it would be done without Replication Manager? Any books on the subject or other resources. I don't want you to spend a bunch of time trying to educate me. Thanks for the info! >> The idea of having the master more or less permanently residing on >> a particular server is the part I'm concerned with. . . . [quoted text clipped - 33 lines] > be a lot less work to move to a Terminal Server-based scenario than > it will have been to set up indirect replication. I did some more research. Googled this newsgroup. I realize that what I am doing is direct and that it doesn't work reliably over an internet connection. I also realize that indirect is a pain to setup and maintain. So my thoughts are now this: Install Windows XP Pro on my wife's business computer and her laptop. Install a router and setup a little peer to peer network at her business. Install the split database on the desktop computer at her business. Make the backend at her business a master and put a replica on her laptop. Occasionally she can bring her laptop to work and connect the LAN and do a direct sync. She won't even need a dialup at work. :) What do you think of this idea? Thanks! > Thanks David. Earlier in this thread you said, "This requires indirect > replication. Theoretically, there's no need to have Replication Manager to [quoted text clipped - 52 lines] >> be a lot less work to move to a Terminal Server-based scenario than >> it will have been to set up indirect replication. > I did some more research. Googled this newsgroup. I realize that > what I am doing is direct and that it doesn't work reliably over [quoted text clipped - 12 lines] > > What do you think of this idea? Sounds great to me. The only change I'd make is *not* to use the Design Master for synchronization hub. That means DM and replica on the server at her office and a replica on her laptop. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thanks David! That's the plan then. (You said, "The only change I'd make is *not* to use the Design Master for synchronization hub. That means DM and replica on the server at her office and a replica on her laptop.") So if I'm following you, I need two replicas? I could just make one and copy it to the laptop as long as it hasn't ever been opened? The original replica will remain on the "server" or desktop at her business? The front end on each machine will link to the tables in the *replica* on each machine? That brings up a couple more questions. Does it matter if both replicas have the same exact name? Seems like it would be easier to distribute design changes to the front end if they could link to tables in identically named database files in identically named folders. Is this the following the correct way to synchronize: Occasionally open the replica backend on each machine (including the desktop at her office) and directly synchronize with the design master using Access user interface? Care and feeding: Compact and repair design master and replicas regularly? Backup design master regularly? Thanks again, Steve >> I did some more research. Googled this newsgroup. I realize that >> what I am doing is direct and that it doesn't work reliably over [quoted text clipped - 18 lines] > synchronization hub. That means DM and replica on the server at her > office and a replica on her laptop. > That's the plan then. > [quoted text clipped - 3 lines] > > So if I'm following you, I need two replicas? . . . Design Master and two replicas, and use the replicas for synching and editing. > . . . I could just make one and > copy it to the laptop as long as it hasn't ever been opened? . . . Yes. > . . . The original > replica will remain on the "server" or desktop at her business? The original MDB on the server becomes the Design Master, and the first replica you make (in the process of changing the non-replicated MDB to replicated) will be the server's replica for editing on the server and synching with remote replicas. > . . . The front > end on each machine will link to the tables in the *replica* on > each machine? . . . Yes. > . . . That brings up a couple more questions. > > Does it matter if both replicas have the same exact name? . . . I assume you mean "same filename," because on a network, they *can't* have the same actual name, because if they had the same filename and were in the same drive/path, the machines would still have different names, so that would make them different names from the standpoint of *replication*, which uses machine name/path/filename to determine uniqueness. Since you can't have two machines with the same name connected to the same network, you don't need to worry about using the same name for the replicas. I religiously use the same names for all replicas, usually some variation on "data.mdb" appropriate to the application (e.g., "cfmData.mdb"). I use exactly the same naming conventions as I use with non-replicated apps. > . . . Seems like it > would be easier to distribute design changes to the front end if > they could link to tables in identically named database files in > identically named folders. I always do it that way. However, there is one exception. For laptops where the user sometimes uses the LAN replica and only uses the laptop replica when travelling, I tend to give the replica a *different* name, and provide a separate front end linked to that replica (usually some variation on "tData.mdb", for "travel data") or automatic link switching based on a command line switch (separate shortcut for launching the "travel data" front end). > Is this the following the correct way to synchronize: > Occasionally open the replica backend on each machine (including > the desktop at her office) and directly synchronize with the > design master using Access user interface? Or you can program your laptop front end to attempt a synch with the LAN copy each time you start the app and each time you shut down. You can do this by checking for the existing of the LAN replica with Dir(). If it's not there, you're not connected to the LAN and skip the synch. > Care and feeding: Compact and repair design master and replicas > regularly? Backup design master regularly? No different from regular MDBs. The DM has to be synched occasionally with the replica set to keep it from expiring, but you have a default 1000-day expiration period, so that's usually not too tough to keep up. As to backups, be careful with backups, as restoring them can result in dead replicas if you don't do it correctly. Keep in mind that a replica set is its own backup. Some of my replicated apps have backup replicas that serve no function but being a backup (with a direct synch to those backups on application close). SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thanks again. I understand now. Except for one concept. You talk about the laptops connecting the the lan replica? "Or you can program your laptop front end to attempt a synch with the > LAN copy each time you start the app and each time you shut down. > You can do this by checking for the existing of the LAN replica with > Dir(). If it's not there, you're not connected to the LAN and skip > the synch." I don't really understand why the "server" works on a replica rather than the design master. And if or why the laptops somtimes connect to the replica on the lan? Originally I thought that only one replica would be required and that the desktop would use the master. You have suggested otherwise. Suggestion taken. I'd like to understand better though. Seems to me that both machines in my case would always use the replicas on their local disk and then occasionally synchronize to the design master. What am I still missing? Are there times they would sync with each other and not directly with the master? >> That's the plan then. >> [quoted text clipped - 83 lines] > backup replicas that serve no function but being a backup (with a > direct synch to those backups on application close). > Thanks again. I understand now. Except for one concept. You > talk about the laptops connecting the the lan replica? [quoted text clipped - 9 lines] > rather than the design master. And if or why the laptops somtimes > connect to the replica on the lan? Well, the server is a server, not a workstation. No one is using it to do work. But, I presume, there are people in that office who *are* doing work with front ends connected to the replica on the server. When the roaming worker with the laptop returns to the office, it's simpler for that work to connect to the server replica, rather than to continue to work on the laptop and synch regularly to get up-to-date data from the other workers. > Originally I thought that only one replica would be required and > that the desktop would use the master. You have suggested [quoted text clipped - 4 lines] > there times they would sync with each other and not directly with > the master? Let's change terminology and leave the Design Master out of the description of daily work. What you've been calling the server, let's call "PC A", and the laptop let's call "PC B." A third person in the office with PC A also works in the database on PC C. PC B travels, so can't edit the replica on PC A when it's out of the office, so PC B has a replica on it. So, you've got two replicas, Replica A (on PC A) and Replica B (on PC B, which is a travelling laptop). The users in the same office as PC A always work editing Replica A (on PC A). The travelling worker edits a replica local to its PC, Replica B (on PC B). So, you've got two replicas, and the travelling user synchs with Replica A when in the office. The question then is which replica the travelling user edits when connected to the office LAN. If that user never works in the office, it makes sense to simply keep PC B editing Replica B and synching changes with Replica A. But if the travelling user works for significant periods in the office, it makes more sense for that user to edit Replica A while in the office, thus obviating the need for any synchs -- the user of PC B would then be editing live data while in the office, the same data as the user of PC C. Now, where you store the Design Master is up to you. But you're not *using*, just storing it. If PC A is your server, that's the logical place to keep it, and occasionally synch it with Replica A in order to keep it from expiring. The keep point that I think you're missing is that synchronization comes with problems and if you can avoid editing data in two places for significant periods of times, it's a good thing to do so. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thought I would take a moment to try and make my thoughts clearer: If I understand correctly you are recommending the use of a synchronization hub. Is this the original replica that remains on the server? Do I synchronize the laptop replica to it rather than the design master? I would also then have the option of adding other machines to the lan including the laptop if I choose to and connecting there front ends to the tables in the replica in the same way a backend would normally be used? Occasionally I would synchronize the original lan replica, which has become the sychronization hub replica to the design master by opening it up and choosing to synchronize. The reason for doing it this way is to eliminate ways for the data to be corrupted in the design master, right? If I wanted to make changes to the table structure I would make the changes to the design master and then open the original replica synchronization hub and synchronize to the design master? Then when the laptop came in and synched with the synchronization hub the changes wold be reflected in the laptops replica? I hope I'm getting it. Thanks. >> That's the plan then. >> [quoted text clipped - 83 lines] > backup replicas that serve no function but being a backup (with a > direct synch to those backups on application close). > If I understand correctly you are recommending the use of a > synchronization hub. Is this the original replica that remains on > the server? . . . Yes. > . . . Do I > synchronize the laptop replica to it rather than the design > master? Yes. > . . . I would > also then have the option of adding other machines to the lan > including the laptop if I choose to and connecting there front > ends to the tables in the replica in the same way a backend would > normally be used? Yes. > . . . Occasionally I > would synchronize the original lan replica, which has become the > sychronization hub replica to the design master by opening it up > and choosing to synchronize. The reason for doing it this way is > to eliminate ways for the data to be corrupted in the design > master, right? . . . Well, the purpose of a design master is to make design changes. Thus, it doesn't have to have current data. Indeed, the data in it is irrelevant. You're not using it for daily editing in order to protect it from corruption or being lost. > . . . If I wanted > to make changes to the table structure I would make the changes to > the design master and then open the original replica > synchronization hub and synchronize to the design master? . . . Yes. > . . . Then when the laptop came in and synched > with the synchronization hub the changes wold be reflected in the > laptops replica? I hope I'm getting it. Yes. The issue you've left out is what replica the laptop edits when used for an extended period in the office. I prefer to edit the LAN replica instead of the laptop replica, since that removes a need for a synch, and keeps the laptop user using the most current possible data. But if there is never any significant period of time when the laptop is used in the office, that's irrelevant. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Thank you very much for all the help. I have a much more knowledge now of what needs to be done and how to go about it. I did a quick test and it worked great. I'm now ready to implement it. Again thanks for all the great advice. The way I was orignally thinking would have been pure hell. This is great! Thanks, Steve >> If I understand correctly you are recommending the use of a >> synchronization hub. Is this the original replica that remains on [quoted text clipped - 47 lines] > data. But if there is never any significant period of time when the > laptop is used in the office, that's irrelevant. > Earlier in this thread you said, "This requires indirect > replication. Theoretically, there's no need to have Replication [quoted text clipped - 5 lines] > Replication Manager. I'm using Access 2003 with no hope of > getting Replication Manager. If you install the Jet 4.0 Replication Security update, it installs all the files you need to do indirect replication. However, apparently ReplMan creates some unspecified registry keys when installed such that indirect replication fails to work without installing ReplMan first. I've not done this, so am just reporting the experience of one poster in this newsgroup. > I have setup a test synchronizing from a replica on the computer > at my wife's business using dialup to a design master on my SBS > server. I simply open her replica and tell it to synchronize with > the design master on my SBS server. It's slow but seemed to work. > I'm sure it's not advisable, . . . It's very dangerous, as if you lose the connection you'll corrupt at least the remote replica (because you're doing a DIRECT synch). > . . . but is > that how it would be done without Replication Manager? Any books > on the subject or other resources. I don't want you to spend a > bunch of time trying to educate me. No, that's not how it would be done without ReplMan. ReplMan is only a UI to replication functionality, all of which is now available programmatically through DAO, the TSI Synchronizer and/or JRO. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi David, Thanks for the additional insights. Again, I'm also looking at this as a network administrator and also in particular the SBS version of Windows Server. >This is a problem, yes. But the solution is not to have bought SBS. >Unfortunately, that option is foreclosed. As a matter of fact, MS further restricts Terminal Services in Windows SBS 2003 (i.e. which the OP uses) compared to SBS 2000. http://www.microsoft.com/windowsserver2003/sbs/evaluation/faq/prodinfo.mspx "It is not possible to run Terminal Services in Application Server mode on Windows Small Business Server 2003. This is a change from Small Business Server 2000. Running Terminal Services in Application Server mode on a domain controller may present a security risk to your network. If you want to use Terminal Services in Application Server mode, we recommend that you purchase an additional Windows Server 2003 license and install an additional server running Windows Server into the Windows Small Business Server 2003 domain." MS's suggestion for TS with Windows 2003 SBS is ... well.. get another Win2k3 server and set it up as Terminal Server which is an overkill for the OP's case. http://www.microsoft.com/technet/prodtechnol/sbs/2003/deploy/adstrmsr.mspx Immanuel Sibero > >> Er, they aren't limited to that. Only SBS limits them that way. > > [quoted text clipped - 34 lines] > serve all its other functions. I'm not certain, but I believe that > an admin can also run a console logon at the same time. > Thanks for the additional insights. Again, I'm also looking at > this as a network administrator and also in particular the SBS [quoted text clipped - 10 lines] > "It is not possible to run Terminal Services in Application Server > mode on Windows Small Business Server 2003. . . ." But that doesn't mean you can't run applications in the two admin TS sessions. I know this for a fact, as I do major Access programming in admin TS logons for several of my clients, and one of them is definitely SBS (though it's 2000, not 2003). There is simply no difference between what you get with the two admin logons and what you get once you've licensed more than that. The difference is that SBS won't allow you to license more sessions than the built-in two (restricted to administrative logons). SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ On XPPro you can add non Admin users to the list of acceptable Remote Desktop users. They do need a set password but I'd be surprised if you would have users without one. I think replication opens many possibilities. Although you can't convert backwards to a regular db you can abandon the replication features or you can export the tables/objects into a new blank (non replica) db and continue that way if it really bothers you. You can buy inexpensive routers with PPTP servers that are easy to setup VPNs for roaming machines. Dlink 8XX series comes to mind. You can also set up Lan VPNs with IPSEC/IKE. Lars > On XPPro you can add non Admin users to the list of acceptable > Remote Desktop users. They do need a set password but I'd be > surprised if you would have users without one. We were speaking of the Windows Server versions, which allow two simultaneous Terminal Server sessions without blanking out the console. XP Pro only allows one at a time, and it blanks out the screen for the local user. > I think replication opens many possibilities. Although you can't > convert backwards to a regular db you can abandon the replication > features or you can export the tables/objects into a new blank > (non replica) db and continue that way if it really bothers you. Of course you can undo replication. There are replication wizards that do most of it for you -- search this newsgroup on Google Groups for "unreplicate" and you'll get plenty of links to tools to unreplicate. > You can buy inexpensive routers with PPTP servers that are easy to > setup VPNs for roaming machines. Dlink 8XX series comes to mind. > You can also set up Lan VPNs with IPSEC/IKE. No extra purchases may be necessary, depending on your working environment, as Windows 2000 and Windows XP include built-in VPN client/server. If there's a firewall/router involved, you have to open up/redirect ports appropriately, but that's going to be required with any VPN. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.