Need some HELP from the network heavy hitters

[wvjohn]

Here's the deal - we were told by HQ we would be upgrading to a new timekeeping system. it is an office by office rollout. we were due to convert today. we didn't. Since I have to implement it on two offices here, I tried to learn as much as I could from HQ. What I learned made me really nervous about the system design. I took my concerns to my boss, who is also a techie, who then identified other serious management/report concerns which are not included here. We decided the issues were serious enough to call the big boss (who is a friendly) and express our concerns. WE had a phone conference which lasted an hour and we picked up a lot of additional info which dealt primarily with management/report issues. He respects our opinions but told us to be good little indians and go with the flow. today we got an email from him asking us to document our concerns more fully. our best guess is that he took our stuff to the IT people and didn't like the answers they gave him. my boss and I have to respond ASAP to his request. It appears we have stirred up a hornet's nest. Some of the tech stuff is frankly beyond my actual knowledge and I'm working on instinct. I obviously want to respond to him with the most accurate information I can.

So if any of you heavy hitters have some time to help me, I'd really apprecaite it.



currently all our offices use a program called time matters for timekeeping etc. we do data entry locally in each office, maintain data on a file server, generate reports on a monthly basis and ftp them to HQ in charleston wv.

We are using 4.0 (hehe circa 1999) which has lots of issues. It is a Topspeed database and pretty useless. For years HQ has been fooling around trying to upgrade everyone. The current version is 9.0 and is sql based. Lexis-Nexis bought time matters a few years ago and sells it as a web-based subscription product. Log on via the internet, enter your data, logoff. Managers and admins can log in a correct data input errors, generate reports, etc. on a real time basis. unified sql database.

The IT group in charleston has been working on an upgrade for several years. IMHO a group of squirrels could have made better progress, but those of you who work for the government know how that is.

We are preparing to convert over to 8.0 (don't ask why) and as the person responsible for implementing this this I spent a lot of time gathering info about the new system and how it will be implemented. This is the part where I'm a little out of my league and I need some help. I hope I can make this clear.

1. Instead of setting up a web-based interface (like asp server or whatever its called) and having a logon like lexis or westlaw (or pca ), each individual user must connect using Windows Remote Desktop/Terminal Server. We are probably talking 250 users statewide. The plan is for each individual user to configure their computer so that they can just click and be connected. Each user will have a different ID, and will only be able to enter data linked to that ID. This seems to me like a system designed by someone who doesn't know how to set up a server. My recollection is that the system they are specifiyng was set up so sysadmins could do remote administration, not for apps like this. I did a little research and it appears the remote desktop has the usual windows vulnerabilities. One of my chief concerns is that the ability of each user to enter data will become totally dependent on 1) their pc being functional 2) the internet being up locally and 3) the server being online. Any simple local problem like a power outage resulting in a router reboot and a reassignment of internal IP addresses can knock someone off the local net because of conflicts. Easy enough to fix, but most users can't do it. Because the plan involves having each user set up a custom profile to access the server, we lose all our redundancy in terms of data entry. right now, you can go to any terminal in the office, log in and enter your data. Under the proposed system, entering your data on someone else's computer would require walking through the connection wizard etc. which isn't going to happen for a standard user. Our local system is used pretty much 24/7 by admin staff. Until we upgraded our local server to a dual quad core, we experienced significant performance hits as more users logged in. Generation of complex management reports still can require 15 minutes on this system. Part of this is due to how old the software is. I have a real concern about what happens when someone needs to generate a complex report on a server that already has 50 active remote connections to deal with. Also each user computer has to purchase a server terminal license at $80 a pop.

Next is the problem of database record structure. we were originally led to believe that there would be a system-wide single record structure. What I learned was that they are instead going to maintain the record structure used by each office in separate mini-databases. Why? Because after 9 years various offices started using different fields in the standard record structure to record data they felt was important and should be captured. The obvious solution is to specify a master record structure, analyze the fields in the current standard structure used by each office and migrate the data. Obviously a major pain (I did this about 15 years ago) but the only way to do it right. The explanation I got was that it was "too hard". lol.

This will be hosted on two cascading win2003 64 bit servers. We're running XP. they said the would post 64 bit printer drivers that we could download and install so that we could print from the server (which will be the only option). When we generate documents related to cases, we link those to the master client record in the database with presumably 32 bit names and locations. I truly don't know the interplay between 64 and 32 bit stuff but I see problems. We also have a database of scanned documents (pdf) which is in excess of I gig and growing.

Any comments about security, system design, 64/32 bit issues or anything else I mentioner (or didn't mention because I don't know enough about it) are truly welcome.

TIA

John

[smb]

I read your dilema. I would not want anyone configuring their system to connect to a terminal server. Sounds like a "cost saving" effort. next thing you know, there won't be an IT group. You really need to look at it from an employment preservation standpoint. I have used that time matters software before, and it can be very finicky synching over WAN. I used it for an EMS stations that were clear across the county.

[FlyingPenguin]

Well it's silly to pre-configure the Remote Desktop (RDP) username and password so the users can just click on it and automatically log in. That entirely defeats your security. The janitor could walk up to someones computer and log into their RDP account.

Also, by NOT configuring the username and password (forcing the user to enter them each time) you also fix your other concern because anyone can use any workstation to login to their RDP account.

[ZYFER]

Yeah, in that case, there is absolutely no security. I can see the benefit of being able to access the server from any internal location, but the process needs to simple. Also, you should go about restricting access from outside the network from the security standpoint of things. You don't need some home computer infected with a keylogger accessing your internal network and recording sensitive information.

What this system will end up having, is people all entering stuff on the same User ID, this causing an entire mess for everything, eventually driving more headache to the middle ground supervisors who have to erect some protocol in handling it, which may or may not result in some success.

Also, you do not want to rely yourself on a WAN. Any number of things can knock your WAN connection offline.

I am a big supporter of the whole idea of: "If it works, don't fix it". If the old system is working, and is working efficiently enough, there is no need to put in place a new system that can wreak havoc on overall efficiency or grind it to a screeching halt.

[wvjohn]

thanks for all the input so far. to clarify, my understand is that a user logged in to the remote server may only enter data for themselves i.e. smith logs in and can only enter data for smith, not jones. If smith's computer has a bad nic, then someone has to log them in as smith on someone else's computer.

good stuff, keep 'em rolling

[FlyingPenguin]

Yes, but if RDP is not configured for autologon, then it's not an issue. Anyone can login to the remote server using their unique user login on ANY computer. Just click on the RDP icon and login as yourself. That's the way it should be.

You don't want another person coming over to your desk and logging on as you (which will happen either accidently or purposely) if it's setup for autologon. Using autologon completely renders any security useless and also makes it difficult for a user to use any computer but his own. You shouldn't need to call an administrator to log into a remote server on a different PC than the one you normally use, and as you well know PCs go down all the time. Thet'll be a nightmare for you.

That would be one of my biggest arguments with the powers that be.

As for RDP itself, it basically works fine, assuming that the eggheads who setup the Terminal Servers are using enough servers and have enough bandwidth. 250 users is a LOT of users. At 30K per RDP connection that's around 7.5Mbit UPSTREAM at the server. Hope they have a fat pipe and have distributed it.

If you lose the connection for any reason then yes, you're down. But the same thing happens with a web based system.

[smb]

speaking of autologin, you know that at least half the users are going to get tired of typing in their password and set it to autologin. Then what happens when a laptop or system is stolen? or a user lets someone borrow the laptop, and the borrower logs in and screws up your system.

[wvjohn]

some good points which which we included!


PCA RULZORZ!