Developing remotely from the deployment server

DaveBarber

Active Member
Recently the business has moved its hardware to a different location from the office where our developers work. (it wasnt my decision!)
Thus our deployment server is only accessible to our fat clients in the local office over the WAN. This causes major problems with WAN traffic for checkouts, check ins etc.
We have resorted to using PCAnywhere and VNC to access fat clients local to the dep server but this is still desperately slow compared to developing over a LAN to the dep server.
Has anyone found any ways of developing effectively when using a dep server away from their fat clients?
I was thinking about Citrix as a possibility or even some way of replicating the deployment server locally in our office?

Any help much appreciated.

Dave
OW XE SP21 on ORACLE win 2000
 
Have you considered putting the FAT Clients on Windows XP machines -
and using Remote Connection (over the WAN) to drive those PCs? Your
developers could 'give up' their beefy desktops - and place them on
the other side of the WAN (and you could give them W98 machines with
64Megs of ram to run the remote machines)...

My good friend Bala (he's here, somewhere, on the list) has built an
excellent Remote Development process - using Terminal Services (it is
just like being there)... you might try to track him down and ask for
directions. He's very busy - but extremely helpful and knowledgeable!

Daniel
 
PC anywhere (at least in my expierience) is a bandwidth hog. If your fat clients are running XP you could try Remote Desktop (RDP). I use it all the time from my home. I have a dsl connection and I VPN to my companies LAN and run an RDP session... almost as good as sitting at my desk.
 
Our computer services have been outsourced for about 1 1/2 years (not IS's decision, either). Our office is in Ft. Wayne, Indiana, and our equipment / service provider is located in South Carolina. We have been using pcAnywhere and Citrix to connect our developers to our fat clients at our service provider. We have also tried Microsoft's RDP (Remote Desktop Protocol in W2K Terminal Services).

Each has its advantages and disadvantages. Microsoft's RDP was noticably faster in interaction/editing, but actual check-ins and check-outs were slower.

I am using pcAnywhere, and find my response time from awful to very slow, depending on network traffic (and no, you don't ever get used to it...)

Other developers use Citrix because their pcAnywhere (same software / PC setup as mine) runs only about 1/2 to 1/4 the speed I see.

We aren't using Microsoft RDP, because there was some extra cost to get it set up, and it wasn't approved (or proposed - we don't know which), but of the three methods it seemed the fastest in the limited testing we did on it.

We did have a consultant talk to us about installing Demo Jr on the local workstations, and using them for development based off of MS-Access. This would be very fast, but causes problems with the check-in, check-out process (have to do it both on the real DV server, and local workstation) - in a particular order; and even then the developers can step on each other by having the same object checked out at the same time. (Its been a while, so the description may be kind-of fuzzy...)

Hope that helps.

For anyone else out there with admin thinking about doing this - do your best to dissuade them from it. At OmniSource and everywhere else I've ever worked where it has been tried, the results are significantly less than desirable.

Among the additional problems we've experienced are:
* Miscommunication between Omni & Source Provider causing delays in critial projects (they thought they were waiting on us, when we'd both agreed the next step was theirs).
* Inability of service provider to execute a process correctly the first time - even with SOP's - this has improved over time, but we still experience a SP's "oops" about once a month -- at least they've finally broken their 100% first time failure record.
* Inability to control / manage our systems - even if we know what is wrong, we have to rely on them to fix it - at their convenience.
* Slow turn-around - for example, it takes them 6+ hours to build & deploy a simple 2-project, 10-object update package. Our CNC guy could do it in 2 hours (and that was taking his time).
* Sales Presentation vs. Reality - sales presentation was that they'd handled all sorts of JDE installations, including ones like ours on an AS/400 using IBM's DB. Fact - ours is their first and (so far) only AS/400 OneWorld/XE installation.

Outsourcing machine hosting may seem like a good idea from admin's point of view, but it provides poor results on a day-to-day basis.

End of Soapbox...
 
The Terminal Server and/or XP Remote Desktop approaches are quite
simple - and your vendor *should* be able to allow you to vpn without
a great deal of hassle or setup.

From the XP Remote configuration - it's just a matter of installing a
fat client on an XP machine, giving remote users privz, setting up the
vpn and tunneling to the machine. If the vender is balking at the
simplicity - perhaps they need to review their technical expertise?

If they don't know how to configure the vpn aspect - you can always do
the *insecure* thing and port-forward from their firewall to the
remote PC (xp client). Basically - state that incoming port xxxx clientpc_ip:3389. this will allow a remote connection through their
firewall and target the client PC on the Remote Desktop Port...

Since I have several folks that hit my demo jr (on W3K Small Business
Server at home) - to look at how I've done a few things - I just
direct them to a specific port and have them use remote desktop. It
works GREAT with W98, W2K, WXP and any other Terminal Services Client
- just point to the ip address and port number (for port forwarding).
I haven't had a need to play with my router and VPN (yet).

Daniel
--
 
We have been using RDP for 6 months and are extremely happy.



Colin Galdo
CNC Administrator
Hanson Building Materials America, Inc.
Voice - (919) 380-2581
Mobile - (919) 795-0295
Fax - (919) 380-2578
[email protected]
 
Re: RE: Developing remotely from the deployment server

Hi All,

I've been asked about the idea to place our OW installation to a service provider, background is SOX. The service provider is a big Telekom company and the access to the hardware is only allowed to the guys of the Telco.

As far as I understood, you have to be physically on the deployment server to run the installation workbench.

How did you managed that?

Regards,
 
Re: RE: Developing remotely from the deployment server

The official line from JDE has always been that you must not apply ESU's or run planner functions using remote access tools. Specifically PCAnywhere has been known to cause problems.

However field experience has show that some software works reliably. I have personally found NetMeeting and Sunbelt RemoteAdmin to work fine. I would agree with the previous poster that RDP works great. I have done whole EnterpriseOne installs from a remote desktop session and never actually touched the console.

Having said all that the official line from PeopleSoft is still the same. So if you run into problems, even unrelated to remote access, they may refuse to help until you work from the console. Hopefully they will one day recognize that a lot of us are working with machines in remote data centers and they will validate and approve specific software for remote access.

Regards,
 
Back
Top