Remote CNC Anyone?

I was indeed wondering when you were asking this question. Actually, JD Edwards have created and distributed a whitepaper entitled "Remote Development Using Citrix and a Windows
Terminal Server" written by Allen Jacot on 2/16/2001.

It is possible, first of all, to install Administrative Mode Terminal Services on the Deployment Server and remotely control package builds etc etc - as long as the user is the sole user on the Deployment Server. I always check to ensure that there are no other users logged in through TSAdmin.exe.

However, if you are looking for large scale remote development and the ability to promote projects and perform client-side update packages remotely (as with a larger enterprise development environment) - then read Allen's document.

In effect, the document is indeed simple in its ideas. The idea is to install oneworld for EACH development user - in their own directory. Of course this uses up significant amount of Hard Drive space (which of course is relatively cheap) - but as long as developers have their own specifications on the terminal server, they do not impact each other.

We have set this up for a customer that has outsourced much of its development to India. During the night, there are at least 25 concurrent developers on the system - and at the overlap between US Timezone and India, there can be as many as 50 developers on the Terminal Server at one time.

However, there are some caveats to Allens document.

1. The development environment should only be set up on a single Terminal Server - having users mapped across a network could cause significant delays in development, although a Gigabit connection to a common share might work well.

2. Do not push out or update the developers packages. Let the developers check out their own objects. If you need to install a new full package, then you will have to copy the package to each instance of the developers home share. This could take significant time, but is much easier than pushing to developer FAT workstations.

I will happily distribute this document if required, however there was a SAR that stated the following :

Title 5434042 REMOTE DEVELOPMENT USING CITRIX / WTS SystemH97

Document Detail Show detailed information.

Call Number 05434042
Status 900 - Closed / Complete
Product OneWorld Technical > Platform Support & CNC
Queue 111141 - OW Tech Platform Support
Reference Call (none)
Taken by Owens, James 7075911
SAR Number (none)
System Code H97 - Benchmarking/Performance
Program ID OTPTSE - Terminal Server
Release Xe
Cum Level C03
Service Pack SP20
Operating System WIN
Platform MICRO
Call Reason C - Code Change
Call From PAUL SHEARER
Customer 7050799 - Agilera, Inc.
Business Partner 7050799 - Agilera, Inc.
Date Received 2003-01-03
Date Returned 2003-01-03
Date Completed 2003-01-23

Description
<Q>
Client wants a copy of a document developed by GATS title "Remote Development
Using Citrix and a Windows Terminal Server".

<A>
Researched for the GATS contacts in the Knowledge Garden. After they verified
if this document can be shared with this BP, they forwarded a soft version of
the document to me, which I forwarded to the BP. It is important to note that
GSS does not enordse this document and will not support any problem that arises
if following the techniques in the document.

This means that although JDE is writing and distributing the document, they are not necessarily supported through GSS - if this is important, then I recommend not performing the instructions. I myself fully support Allen Jacot's document and believe it is an excellent - and probably the only method to implement remote development functionality.
 
By the way,

I did find the following support call as well on JDE Knowledge Garden :

Title 5666305 IS XE DEVELOPMENT ON A TERMINAL SERVER CURRENTLY SUPPORTED? SystemH93

Document Detail Hide detailed information.

Call Number 05666305
Status 900 - Closed / Complete
Product OneWorld Technical > Platform Support & CNC
Queue 111141 - OW Tech Platform Support
Reference Call (none)
Taken by Almeida, Paulina 7554102
SAR Number (none)
System Code H93 - Database and Communications
Program ID OTPTSE - Terminal Server
Release Xe
Cum Level BASE
Service Pack SP20
Operating System Windows 2000
Platform Intel/HP-Compaq-Intel
Call Reason C - Clarification
Call From CRAIG BAUER
Customer 24785 - Royal Caribbean Cruises, Ltd.
Business Partner -
Date Received 2003-05-16
Date Returned 2003-05-16
Date Completed 2003-05-16

Description <Q>
XE development on a terminal server



<A>
There are no plans to support development on the terminal server.

Please refer to the Server and Workstation Administration manual which states
"Currently JDE instructs customers to perform all development on non-TSE
machines." pg 6-19. The only development that is supported by GSS is documented
in the Knowledge Garden Document ott-01-0028-WTS and RDA (Report Design Aid)

This therefore states that the document IS indeed supported, and since the date is much later than the previous quoted SAR, it should be assumed that it overrides the preceding call.

Email me if you cannot find a copy of the document on the Knowledge Garden.
 
Here is a totally different approach. Has anybody had any experience using a hardware solution to this problem? Our network group has mentioned something known as a "remote access card". You install it your server and then you are able to access the server via an I/P address. With this solution there is (possibly) no need to worry about what impact "non-certified" software (PcAnywhere, Dameware, VNC, etc) will have on One World.
 
Hi List,

I use a hardware solution. Our Deployment server is on a Compaq/HP server with a 'Remote Insight Board' installed. This board allows me to intercept the monitor, keyboard, and mouse at the hardware level.

I have found it a bit slow, but no slower than the software alternatives. I have used Netmeeting and PCAnywhere and found that they all were ok. I did have problems with VNC after our latest server upgrade. The screens would sometimes hide the top buttons in the OW screens, escpecially during a package assembly. I also had a lot of problems creating custom plans and using the workbench while using VNC. I had to come into the office to run the workbench because I would get memory protection errors. I since have started using the hardware solution and have had no problems what so ever.

I found the hardware solution to be the best. The Remote Insight Board allows me to do a soft or cold boot of the hardware as well.


KD
 
Tom,

Run away as fast as you can! Other than the novelty factor of using a hardware solution like a "remote access board", they suck. You access a "remote access board" using java through your browser. It is painfully slow compared to a software based solution. To add to the mayhem, your pointer from your mouse does not always track where you want it to go and you end up doing a quarter inch offset when trying to click on an object. We tried it and then had the hardware guys yank it out of the deployment server. We have been using net meeting for the last 30 months. Other than the occasional screen not painting, it works fine. When we run in to the screen not painting issue, we just close out of netmeeting and get back in where we left off.
 
Greg,

Thanks for you input. I am not all that concerned about response time. I would only be using remote access to start a full package build or recompress. Even slow response is better than coming down to the office for five mintues to start the process. I just don't have that warm fuzzy feeling about all of the software solutions that are "not certified" byt JDE.
 
Hardware remote control ? Yuk. Every time I've seen it, it stinks. Not only is it costly, but often the application is horrendously slow across a wide area network, to the point where it freezes almost continually.

VNC has its drawbacks - but it works well across wide area networks. Sure - JDE screens go funny every now and then - but thats because JDE calls non-standard GDI calls in their software, not because VNC is bad.

Netmeeting works well too.
 
The new hardware boards in the Dell Servers actually switch to VNC after it makes it past the text part of the boot process. It is pretty slick.
 
You get the same issues with memory violations with PCAnywhere as you do with
VNC, the cure I found is to set the video mode to 'compatibility' instead of
the default 'accelerator enabled'. Not sure is there an equivalent in vnc,
would be interested to hear..
Regards
Kieran Fitzgerald
 
Create a datasource that looks like "local" (everything points to "LOCAL") with a name that isn't "local" - we use "TS Local" for example. Then it'll appear fine.
 
Sorry I missed this thread.

An answer to runnning UBE's Locally on terminal server:

Running UBE's Locally on Terminal Server

All OneWorld does to eliminate the Data Source "LOCAL" from appearing in the list of available
Data Sources on Terminal Server is generate a SQL statement like this:

SELECT OMDATP, OMSRVR, OMDATB, OMLIB, OMOCM1 FROM SYS7333.F98611 WHERE
( OMOCM1 = 'SVR' AND OMDATP <> 'LOCAL' )

This statement will return all Data Sources except LOCAL. OneWorld does not use code to disallow the
processing of UBE's on a Terminal Server, it uses an exclusionary SQL statement!


To get around this all one needs to do is create a copy of the Logical Data Source LOCAL and name it
something other than LOCAL. You can call it UBELOCAL or even FRED if you like.
 
"I've just setup a 'bank' of desktops running Windows 2000 Terminal Services, which are primarily going to be used for development by remote users. "

Just curious, have to given one terminal server 'desktop' to each user or are you sharing the terminal servers amongst multiple developers?
 
We have allocated one machine per remote developer. It is too confusing when two developers share the same machine.
 
Again, there are different ways to handle this. Having a single developer use a single machine is the simplest method BUT for those who wish to use the power of Terminal Services/Citrix - it is indeed possible having dozens of developers connecting to a single Terminal Server to perform development. To do this, read Allen Jacots whitepaper on setting up Oneworld for remote development. A link to this whitepaper is available here :

http://www.erpsourcing.com/modules.php?name=Downloads&d_op=getit&lid=39
 
I've been used RDP connection (WTS) through a VPN link. It works pretty fine even from outside Brazil.
 
I'm with you mattkosht.

I did an upgrade from Xe to 8.10 (from test to go-live over several months) from my living room via VPN to the Corporate Office and remote desktop to a Windows 2003 Deployment server at one of our remote divisions. I didn't have any issues except the odd loss of VPN connection. Our Development team at the Corporate Office connect to a Windows XP machine for development work.

Remote Desktop works great. I support the remote division from corporate as well. I have the new Change Assistant installed and I can do ESU's, SP's and the package builds. We even use remote desktop for the web generations on that division's web server.

Kevin
 
Hi,

We currently use the Terminal Services on our Win 2003 deployment server. I have not had any issues with this since we set this up last year. The ESU's and package builds have been working fine remotely.
The TS connection connects as a console(0) connection and what I do remotely can actually be seen on the console monitor, similar to how VNC worked, but it seems to be more stable.
I did have to set up the jde.ini file on the server to include the OWDEVELOPER=TRUE under the [DEBUG] section and I have to use a local admin acount to log on the server(Becasue of our roaming profiles and default user directories etc.).

Karry.
 
Wow! What a chain of posts. There seem to be quite a few threads being handled here. Most have been beat to death, but two still have a little life left. Let’s see if we can kill them.

The issue of being able to safely and reliably control the deployment server remotely: Yes. It can be done and that, safely, if you use VNC or some other connectivity method and use RDP or TS at the server level. Kevin Gray, you said that you did the entire upgrade from XE to 8.10 remotely. I have found that the only thing that can’t be done remotely on the DS is the Spec Merge (or Table Merge – I always forget which one since I always do both locally) during an upgrade. It works fine during an ESU, but not on an upgrade.

Packages on the deployment server: For those of you interested, FULL packages will build fine on the deployment server and since it’s usually in the server room, physically and logically closer to the data, the build runs faster from the DS. However, if an update package has a version (other than one that exists in DEP7333, DEPB810, etc like ZJDExxxx or XJDExxxx) the DS will not see them during the assembly when you’re selecting the objects’ versions. This phase of the package can be done on a workstation and the package will build fine on the DS or the workstation.
 
<Insert sound of me beating the horse that Alex Karras just punched out - I wouldn't do that to a dead one!>

We use DameWare for remote control and performed our last upgrade in 100% remote mode (even though the data center was directly below us.) Yes there were a couple of workbench related memory violations, but they occurred in the same place for each environment and we were able to plan for them accordingly (after all, what kind of CNC worth his or her salt doesn't test, test and test some more before going live in the production environment?)
 
Thats a lot of interesting points there. So thought I would also add some more.

Ken, I would like to back Kevins statement(doing entire upgrade remotely), by addign that I also did 2 complete Upgrades Xe to 8.10 and 8.10 - 8.11 remotely, all workbenches ,Spec merge , TC etc etc. No problems. I did however use NetMeeting's Remote Desktop sharing feature. I have seen that softwares like PC'Anywhere do cause memory violations during ESU or Upgrade workbenches but NetMeeting works just fine.

The only thing I havent tried remotely as yet is the Deployment Server Install. But I am sure that should also go thru fine remotely
 
Back
Top