Deployment on 24x7

Hello List:

My configuration is this:
1. OneWorld Xe (Base), SP21 on Windows 2000 Advance Server
2. SQL Server 2000 SP 2.
3. About 500+ users around the world, connecting to OW using Citrix, running 24 x 7
4. Development in progress
5. Full packages build every day (different pathcodes)
6. Package deployments every day.

For the deployment of the packages, we have one hour where we kick all users off of the system. This give us the safety to deploy packages clean.

Full packages to the Citrix Servers are taking less than 3 minutes using the Silent Option (Thanks to Tim Allen for the lead). Deployment to the Enterprise Servers are taking 10 minutes to complete.

In general, we are using only 15 minutes for package deployments every day. This is working very, very good and the project is very smooth.

But, I'm facing more and more pressure from management to deploy packages without kicking users off of the Citrix Servers.

Does anybody knows which will be the best approach for that?

I know I can deploy packages to the Enterprise Server without kicking users off the system, but only to those pathcodes not being used. But Citrix server are a different beast.

Does anybody has a good idea to approach this dillema.

Thank you all

Can you tell me what the 'silent option' is that you mention when deploying packages to Citrix Servers.

Thanks

Roger Breakell
One World B7333(XE) , SP 20_Q1, Oracle 8.1.7.4 on Sun Solaris

Are you trying to deploy packages to the Citrix Servers while users are still logeed into OneWorld, or are the users just connected to the Citrix Servers using other applications?

Thanks,

Hola Jorge

We have a similar configuration but not the constraint of manditory 24/7. We treat our system like 24/7 but we set up a service level agreement with the business side of the company that guarentees up-time (or super fast troubleshooting) Monday thru Friday, 7:00 am - Midnight. This gives us some maintenance windows to do package deploys. It also means that I work very strange hours and work a few hours every weekend. Oh well, at least they pay me less than the industry standard for CNC work. But that's another story.

We have our package deploy to our 14 production terminal servers down to 15 seconds (yes seriously!). Here is our process:

1) Build a full package, Client and Server
2) Deploy the client package to a test terminal server (no production users on that server)
3) Run R98CRTGL for Jiti.
4) Run R92TAM for Data Dictionary (I do this once a month)
5) Use a batch program to copy the pathcode out to all production terminal servers with a .new extention on the directory. {Example, PD7333.new} This copy process takes about four hours to run.
6) At an off-hour, run another batch program to connect to all terminal servers, change the name of the pathcode to {Pathcode.old}, change the name of the directory {pathcode.new} to {pathcode}. Example: Connect to Terminal server A. Change {PD7333} to {PD7333.old} Change {PD7333.new} to {PD7333}

Assumptions: no users are on the system. I check in the Citrix Admin console for users. If I find any on the system, I send them a message to log off. I give them two minutes before I forcefully disconnect them. Since we have an agreed upon set of hours that IT does not touch the servers for maintenance, any straggelers that are on the system at weird hours that are kicked off have no grounds to complain.

The server side deploy process is a little different:
1) On Enterprise server, create PD7333.new directory
2) Copy the Bin and Spec directories from the Package directory to the PD7333.new directory
3) Copy the PD7333.new directory to the two logic servers
4) During off-hours, log on to the enterprise server. Stop JDE.net and JDE.queue services
5) Rename the old PD7333 to PD7333.old. Rename the PD7333.new to PD7333
6) Restart services
7) Repeat process for two logic servers (Note - the enterprise server has to be done first. Once the services are down on the enterprise servers, the logic servers lose their connection to the system and need a service restart)
8) TEST - now that I have a new client and server package installed, I log in to Oneworld and make sure that applications, data and UBEs work.

You may have noticed that I mentioned that we always build a full package. Once in a blue moon we'll do an update package for an out of cycle deploy. Our standard is full for all pathcodes. We do this out of necessity. We have users connecting to our system from four countries that could be making version changes. I have developers for two countries modifing code. We have no good way of ensuring that all changes are incorporated other than doing a full build. We build a full Dev, PY and PD every week.

Configuration:
Windows 2000 Clustered Enterprise Server (SQL 2000)
Fourteen Production Terminal servers, One Test Terminal Server
Two Logic Servers
One Websphere Server
One XPIe server
One Deployment server
Sandbox servers (Enterprise, terminal , deployment and Websphere)
And a partridge in a pear tree!!!!

Gregg Larkin
North American CNC Guy, Praxair

Jorge,
this issue has been discussed some time ago and I remember that Mark
Siebenschuh had a good suggestion then. You may want to search on the LIST
for that.

You are saying that "I know I can deploy packages to the Enterprise Server
without kicking users off the system" . I think it's not that easy.
When you start the deploy to the ES OW will hold all UBEs in the queue,
however it will allow any already running UBE to complete. What if just one
second before your deploy-process starts, a UBE kicks in and runs for one
hour. Then your deploy will take one hour plus 10 minutes. And during this
time no other UBE will start. And if you are executing BSFNs on the server
('W' or 'J' environments) not even the BSFNs get executed. Execution will be
suspended for all pathcodes, not only the one you are deploying. I wonder
what an interactive user would say if a screen took 70 minutes to respond.

My two centavos, Gerd



B732 - ERP8, Unix, Windows, Oracle, SQL, WTS, JAS

Hi Roger,
They're referring to doing a command-line installation of a package. There is a KG doc for this: OTM-00-0067 "Installing Packages from the Command Line". For example, to do a silent install of a package, you can run the following, either from the command line, a batch file, a .vbs script, or from the Windows scheduler on the machine where you want to install the package:

"\\DEPSERVER\b7333\OneWorld Client Install\Setup.exe" -d c:\b7 -p PACKAGE -s -e H

Where DEPSERVER is the deployment server and PACKAGE is the package name to install.

-d c:\b7 -> Specifies the disk to install to
-p -> the package name
-s -> silent installation
-e H -> Show lots of detail in the install log

There is also a "-c" option (compact) which does not install development objects. The default is to install them. However, this option gives me an error, and I've read in another document the the correct option is "-t Compact". I've never tried that, though.

The "-e" option takes various arguments, but I like "H" because it prints everything. The others are "I" for information, "W" for warning and "E" for errors.

NOTE: if you do this on a Terminal Server, you'll need to put the machine in install mode before you start-- there is a command line which you can use to do this:

change user /install (to put in install mode)
change user /execute (to put in normal mode)

Or you can start the setup from "install programs" in the control panel-- but obviously this won't work in a batch file.

Also you'll need to kick all of the terminal server users off of the system before doing the installation, or setup will not work. Hope this helps.

Hi Tim

I like the sound of this for Citrix server installs. The silent install works well but poses a few other problems when dealing with Citrix servers. Have you come up with commands to:

1) Disable user logons prior to the install
2) Send a message to users to ask them to log off the server
3) After a period of time eg 10 minutes kick off any residual users who have not logged off.
4) Enable logons after the installation has completed.

If all these things could be done in a single batch file and scheduled, then life would be a whole lot easier.

Regards

Marty

Re: RE: Deployment on 24x7

Gerd:
Thank you for your feedback.

I agree with you that we can deploy a package when nobody is using the pathcode. We manage that kicking off everybody from the system and restarting JDE services.

Because I agree with you in all your points: Use of pathcode by users, bsfn or ube is that I have not find a "perfect" answer for my management. But they are putting more pressure every day to avoid outage of the system, while keep deploying the packages.

Regards
Jorge


PD: Still in Sao Paulo?

Greg:
I strongly believe we are following the same process, but using different approach. In fact, this is the first time I'm using Full Pkgs, and I think is one of the reasons for the smoothness of the process. Today, I'm building full pkgs in less than 4 hours. How long is taking for you?

Also, can you share with me how are you allowing remote deployment? That's looks like my next research.

I will say that the 15 secs looks very nice, but even that time will require a outage, not to mention the restart of the JDE Services.

My management is trying to any outage, to show a better support for our users. I'm still looking a way to accomplish that, but have not find the perfect one.

Unfortunately, we have people in 15 countries around the world and around the clock, so, we don't have the luxury ot the night: While America is sleeping, Asia is working and Europe is the middle and so far... .

Thank you very much for your notes and I share with you the long days, short nights and an empty wallet and the end of the week

Jorge

Well, that's my management goal, deploy a full package for one pathcode, while users are using the rest of the pathcodes.

Please... no comments.. I know what it means, and I have not found the answer my managers are looking.

Thank you for your feedback.

This is something I always wanted to write, but now that you have prompted me, I finally did.

http://members.optushome.com.au/apastuhov/tse_commander.htm

Regards,
Alex.

J,

You do have the option of running one set of services for each path code. We do this now for our production path codes, we run a production path code PD7333 for English/Western European & PDJ7333 for Japanese. We only take down the appropriate instance for the deploy. We don't run 7X24 we run 5X24 + 2X23. (We deploy 2 production packages to each instance a week.) You would need a separate TSE farm for each instance, but if management is adamant about what they want, they should be willing to pay for it.

If they are not willing to pay for it, you could go to a Saturday night deploy, Greggs 15 second outage at 00:00 GMT may be a reasonable compromise.

Tom Davidson

¿Cómo es usted Jorge?

My full packages take about four hours to build as well. I don't have any remote deployment issues. All of my terminal servers are located in the same data center as my deployment server. The only fat clients we allow are for developers. Those are also located in the data center. Our developers use PC-Anywhere to access the fat clients. One experiement that we are trying is using VM-Ware for the fat clients. The architecure for VM-Ware is pretty cool. Take a Big Monstor Server with a whole lot of disk space. Use VM-ware to "virtualize" a fat client. Connect to the fat client through PC-Anywhere. Our infrastructure guys "virtualized" my remote Windows 2000 PC that I use as a fat client and web generation machine. My end-user experience remains the same. The JDE software does not have a clue it is on a server instead of a workstation. My web generations speed up considerably. Very Cool!

As for planned outages, my management team is more realisitc. You can't deploy packages without an outage. Our terminal server outage time is minimal, 15 to 20 seconds. Our enterprise server outage time is longer. Roughly 5 to 10 minutes per enterprise server. I have three that I need to take an outage on. I can't think of a good process for your enterprise server(s), but I do have something for you to think about for your terminal servers. Break up your terminal server farm into multiple application sets. Let's say you have six terminal servers. Designate two servers for America, two servers for Europe, two servers for Asia. That way you will always have two servers that have no users on them that you can do your deploy to. It means having to do the client deploy three times in a 24 hour period, but at least you're not chasing off any users. If you have operations people scattered around the globe, you can use that to your advantage as well. Asia deploys for Europe, Europe deploys for America, America deploys for Asia. Everyone works sane hours. It's a concept that Praxair will be evolving in to. We are going to be running the JDE servers for Asia starting next year out of our Global data center here in the US. I will be swapping workload with my Asian counterpart. He'll deploy my packages and I his. Should be interesting.....

Gregg Larkin
North American CNC guy
Praxair, Inc.

Greg,

Would you happen to have a sample of the batch program that you use to copy the pathcode to all of your production terminal servers? We are also a 7/24 shop, and I would like to create a maintenance window for our site for package deployments.

Thanks,

...Bryan

Configuration:
Twenty Production Terminal servers.
Three Logic Servers (Oracle 8.1.6, Sun Solaris)
One Deployment server
One Websphere Server

Hey JDEDork

The Process:

1) Deploy Full package to Test terminal server
2) Run R98CRTGL
3) Replace Data Dictionary Files in Spec directory with output from monthly run or R92TAM
4) Run Batch Program One to copy pathcode to terminal servers
5) In off-hours (Wed or Saturday @ 5:30 am) run Batch program two to swap out directories
6) In working hours, run batch program three to clean up old pathcodes.

By the way, as a policy, we keep the previous full build on the server for at least a week incase we need to "roll-back" to a previous build. Maybe once a year or so, something will sneak past our testing process and a "bad" package will be deployed. Since we keep a copy of the previous package "hot" on the server, it is fairly painless to roll-back to the previous package. Attached is the batch program one. I'll send you the others off-line.

Gregg

Gregg,

Thanks for your help! I'll give this a shot and let you know my results.

...Bryan

Gregg,

Our network administrator would be very interested in this process. Could
you send me the batch files or load onto the JDEList "Download" section.

Thanks.

Dave Rammer
Sheboygan County IS Dept
XE u/2 w/SP21_J1 / Ent: HP9000 11i / Oracle 8.1.7.3 / App: W2K
New metaframe: W2K w/Citrix XP FR2 Old metaframe (still some
users): NT4 w/Citrix 1.8

Gregg,

Our network administrator would be very interested in this process. Could
you send me the batch files or load onto the JDEList "Download" section.

Thanks.

Dave Rammer
Sheboygan County IS Dept
XE u/2 w/SP21_J1 / Ent: HP9000 11i / Oracle 8.1.7.3 / App: W2K
New metaframe: W2K w/Citrix XP FR2 Old metaframe (still some
users): NT4 w/Citrix 1.8