Our company is rolling out new PCs and we're looking to see if using Worktop (WT) 2.2 might be valuable to the end users while we have the ability to set up their pcs. After looking at the WT guides, I've got some questions I'm wondering if anybody else has some light to shed on:

1) If my users run the worktop_client.exe program from an NT server, does the NT server do anything besides serve out the executables that allows the user's client machine to run? In other words, the user doesn't run anything on the NT server that would take resources like memory, cpu, etc?

2) It says WT can not be used centrally deployed with BaanIV. Has anybody been able to get this to work or have any information on it? Specifically, I'd like to not have to physically install new BW clients when a new release comes out.

3) Anything I should be wary of when trying to use WT. In general, do the user's like it, does it create more problems for you, specific lessons you've learned would be appreciated.

Hi Chadwickh,

We are on the Unix. But we had few issues with Worktop on the Windows-NT/2000 work stations.

1. -- No Idea.

2. Central deployment is a good feature of worktop but its a pain if a user is accessing across a narrow bandwidth network. Its better to use the local BW and Worktop and you can automate the process with the use of SMS packages.

Microsoft System Management Server
(SMS). SMS is a system management environment for corporate networks, which consists of one or more LANs. SMS allows its user, among other things, to distribute software across one or more LANs. SMS itself is not discussed in this appendix. For a description of SMS, refer to the Microsoft System Management Server Administrator’s Guide.

3. Case 951037 - Cannot start newly installed Worktop for users without NT User Local Admin perm on Windows'2000 workstations.

"In this case Worktop is locally installed. When Worktop is locally installed, Worktop assumes that the user has local admin permission and will try to register the BWC file into the systems registry. If this does not succeed, no connection can be made with the Baan server and neither menu's can be expanded nor sessions can be opened. There are two possible solutions:

-i- Since the user is no local admin, an administrator obviously installed Worktop (since the user can't). Besides installation, the administrator should also create the BWC file and Worktop document. This will register the bwc file used onto the client machine. Now when the user logs in, he will be able to use the document but not to create and use new Worktop documents him\herself.

-ii- Use central deployment. In case end-users are not local admin, it's better to use central deployment, specifically designed for users with low access rights. In this case just install a Worktop server, enable the document (from the Administartor menu; Setup Central Deployment) and send the shortcut to the end-users. In central deployment mode, Worktop does not require registry access. Note that central deployment of course also decreases maintenance costs..."

For more info refer to the BaaN Support site for -

Disable local password storage and usage (BW) using policy template.

Author K Van den Creation Date: 18 Feb 1999 Alternate ID:
Solution No: 19276 Solution Version: 1.0 Status: Published
Product: port6.1c.03.01 Sub Product: Session: bw
Package: tt Version: B40 Release: c
Solution Type:

Linked solutions
13743 Latest version of Setup for Client Binaries (bw.exe, becs.exe, bwprint.exe, etc)
9900 Disable changing of BW Configuration (B51_a) / BW permissions

Symptom information
Would like to disable the save button on some BWC files.
How can we lock users out of the configure screen in BW on terminal server?
BW Client configuration

Solution description
VERSIONS:

From the following version the policy template (bw.adm) is delivered and supported:

BaanIVc: BW version B40c.046 and onwards
BaanERP (Grieg): BW version 6.2a.03.117 and onwards
BaanERP (Verdi): BW version 7.0b.103 and onwards

I hope it helps you out.

Hi Chadwickh,

Here are the answers to your questions;

-1- No, that's correct. The only thing the Worktop_client.exe actually does is comparing a possibly locally chached version of Worktop with the one installed on the server. If the one of the server is a different version, the Worktop_client.exe downloads the Worktop files from the server, stores them in a cache (temp dir) on the client and runs them locally. So all processes really run on the client machine. The server therefore is actually only a file server. And so it can be a low budget server, even a P90 with Windows 95 on it...

-2- Central deployment on Baan4 is indeed not supported, officially. However, the reason for this is that it never has been tested. But i do know some customers using BW centrally deployed on Baan4 and i'm using it myself. Theoratically, you can run into problems when using client specific parts like BW Print for example. So my suggestion is that you test whatever users must do in Worktop with a centrally deployed Worktop on Baan4. If no problem occurs, why not use it? So "not supported" doesn't mean necessarily that it won't work... (same as Worktop on Windows ME, we all know it works, but is not officially supported)

-3- I don't think i would be the right person to answer this question since i am both consultant and engineer on Worktop... But i do get many positive feedback from the field and know at least 14 customers running Worktop on BaanIV.

I always encourage using Central Deployment supported by Worktop itself. Of course there are other ways like SMS and Terminal Server, but the central deployment mode has specifically designed for such an environment. Therefore you will have more options and features available using this (like for example sending messages and shortcuts to Worktop users and centrally maintaining their configurations) and you can really get the most out of central deployment; bringing the TCO to a minimum. Currently, i think about half of the customers is using the central deployment mode of Worktop.
There are also situations thinkable like a "mix" of Worktop's central deployment and SMS. For example, you can centralize the configuration by installing a Worktop server holding all Worktop documents but you can distribute the Worktop client software by using SMS...

If the bandwith within your company is large enough (10Mb LAN for example) i would have no doubt at all: use central deployment. Only if your bandwith is low and have users dialing in using a modem for example, SMS or Terminal Server might be a better option.

If you need more info... just ask.

Regards, Ivo Ladage

When you say "But i do know some customers using BW centrally deployed on Baan4 and i'm using it myself. " How do you centrally deploy the BW client? So let's say I'm on a pc without Worktop or the BW client. I can run worktop from an NT server using the worktop_client.exe program and it'll deploy itself to the user's pc. How does it take care of BW? From where does it run the BW client and how does it know when to get updates/changes? The more specific the better - thanks!

Hi Chadwickh,

When you use the automated process of enabling CD within Worktop itself, BW will be 'enabled' for CD also by Worktop. So if you use the "Setup central deployment" option from the "Administartor" menu in Worktop, both Worktop and BW are centrally deployed. In fact, a user doesn't care that they are technically different applications.

If you use the CD option, this is what will happen with BW:

-1- When Worktop is launched, it first determines the server version of BW. Say for example this is B40c.66.

-2- Now Worktop first determines wether a local BW installation is avialable of the exact same version as the one used by the server. If so (in the example; if it is B40c.66), it will use that BW installation. If not, it will retrieve the files from the server at runtime. Note however that on the contrary to Worktop, BW does not cache its files on the client. So it will download the BW files each time you start BaanERP. In a standard LAN environment this is not a big problem.


Most important issue to consider is what type of central deployment you are going to use. For low bandwith networks, you'd better choose for remote installation using SMS but centralizing the Worktop documents (i.e. Baan configuration). This in fact will have the same functionality as CD offered by Worktop but replaces the automatic update by Worktop with a SMS update. But the configuration still is centralized and so end-user configurations (like settings set in the .bwc file but also template Worktop documents) are still centrally stored and maintained by the administrator. The big advantage is that no end-user will have to create their own Worktop document or .bwc file. They only receive a shortcut and login by e-mail and off they go...

Regards, Ivo

Hi there,

two comments to the central deployment issue:

1) Central Deployment of bw

We do this at several sites. Very easy. Just install the bw client on a NT server (or even into a samba share) and share the directory.

On the PC's just put a icon on the dektop calling the binary on the share.
This works fine, even though you might run into trouble with bwprint. Not quite sure here!

2) Central Deployment of worktop.

This works also fine, apart from two things:

a) If you enable central deployment (with Baan IV), it will warn you, that this will only central deploy the worktop itself and not the bw client.

This is true. If you then use a central deployed worktop together with a local installed bw, everything is fine.

We tried actually to fiddle around with the worktop config files to convince worktop to also work wth a centrally deployed bw client (see above). This failed. Why?

It looks like, the worktop is communicating with the bw client via COM and OLE. This in return, requires proper registry settings for bw on the client. Thesw are obviously missing.

If you somehow manage to distribute these, it should work. But then you might also distribute the whole bw installation, right?

If anybody gets worktop AND bw centrally deployed together, let me know!

Regards

Markus

Hi Markus,

Worktop indeed uses OLE and COM to communicate with BW. The usage of COM has one big disadvantage: COM objects must be registered locally. However, for Baan 5 we found a workaround (MS has a hidden running COM object table which can be used to bypass the registry) and so central deployment on baan 5 is completely registry independent.
For Baan 4, registration is still required. However, this is done automatically. As soon as the end-user has write access to the HKEY_CLASSES_ROOT part of the registry the BWC file will be registered and BW will work centrally deployed (except for the BW print part etc. as described above). If the user does not have write access, Worktop will throw an error.
As an alternative, the system admin can open the document under his\her NT account once. This causes the .bwc file to be registered and so the end-user can work under restricted OS permission with Worktop in Central Deployment mode.

Regards, Ivo