Client W98 names -- network "Idenfication" tab vs. DNS "Host" name

[awnews]

Using RMS 6.5 and Clients 6.5 on Win XP, 2000 and 98 (and 95?) PCs. Network is managed by a Windows 2000 Server box (domain were applicable).

 

I've had several occasions when, after setting up the Client on some Win98 PCs with unique Identification tab names (and a domain), I would go back to the server and be unable to find those names in the Add client list (Piton Multicast). Instead I could see several clients that appear to have the same name (e.g. AABB). I *think* I've tracked this down to the name specified in the DNS Configuration tab, where a Host name and domain can be specified.

 

It *seems* like the Host name (e.g. AABB) is taking precedence over the Identification tab name (e.g. OnePC), at least to the Piton name server. Is this correct and does it make sense? Is there a way to control it? If I select the ID (directly, by IP address) then Add it, doing a Properties on the client shows the IP and the Network "Identification" name (OnePC), not the "Host" name (AABB). In general under Windows & a Windows network, when is the Identification name used and when is the Host name used?

 

Is there a way to control this to get the expected name? One of the Add Client options? I'm guessing that I'm going to have to work my way thru the W98 PCs and make sure the Identification and Host name match to resolve this.

[awnews]

So I've pretty much verified that, under W98, the Retrospect Client gets the client name from the (TCP/IP => DNS =>) Host tab rather than the Identification tab. Under XP there aren't two name locations so the single and obvious "computer name" tag is used.

 

However, I also found something annoying and *unacceptable." After the client name is set, there isn't a way to change it (proven under W98, even as a registry setting (??). I assume this is true under XP as well)! Even if the machine name (Host or Identification) changes, the Client name remains the same. I assume there's the lame expectation that the user/admin can/will/must reinstall the program to change the name. But having the client name remain the same and be unchangeable is horrifically bad. As PCs are moved around, the IP address can change (DHCP or static) and the "name" will change based on theme, owner, function or location (Jupiter, SallyPC, Server2, Room3, etc.). Having it retain the single and now obsolete name makes the system unmanageble as PCs are moved and retasked since there's no way to uniquely ID the machine from the server (!IP given DHCP). And this is Client version 6.5, not 0.2beta!

 

It's also been noted that the password selected at install cannot be changed. The user/admin is expected to deinstall and reinstall the client.

 

Let me help you out with a much better UI:

 

1) On install, have the Client extract a name (Host, ID, computer name) and "propose" it, allowing the user/admin to change or set the name during the install.

 

2) The user/admin also sets a (Client admin) password at this point (true now, but only used for Retro Server access over the network).

 

3) At any time, the user/admin can open up a Client config panel *protected by the Client admin password.*

 

4) From this config panel, the user can change the client password *or* change the client name.

 

5) This password-protected config panel should also allow the user/admin to select which client options can be changed with and without a password (e.g. priority, read only, etc.).

 

6) To make this *really* easy to manage, there should be a provision to change the name, password, client config options, etc. form the server. There is a "rename" ability on the server but I'm under the impression that this only changes the name the Server uses to refer to the Client, not the actual (Retro Client) name seen on the client, when doing an Add or client scan, etc. The fact that there can be two names can be very confusing.

 

*Please* address and fix this. These limitations make the program unsuitable for a large or dynamic network that needs to be backedup and maintained with minimal effort.

[awnews]

As a followup, I'm looking at an "Add Client" screen showing me:

 

10

10

fusd

fusd

fusd

rm3_pc

...

 

The top five "odd" items are shown because the PCs were poorly named (although this is just the "Host" name and not the "Network Identification" name, so there's no network conflict as Windows seems to use the later while the Retro Client uses the former) when they were set up. So the Retrospect Client (with an inability to change client names) took on those odd values. I *can* Add the clients and then rename them, but this is a poor workaround since the client names can & will change as PCs are moved around and retasked. As mentioned previously, it should be possible to rename the Retro Client from the client PC (and the server).

 

I have an "advantage" at the moment because the IPs on PCs have been set up statically. So I can resort to Adding the client and then looking up the IP to ID the specific machine. This "feature" is going away in the next few months when the whole network is switched over to DHCP. At that point, it would be a difficult task to ID which PCs these odd names corresponded to.

 

But this brings up another shortcoming in this area. When doing an "Add Client" and looking at the client screen, there's no way to click on a client name and bring up a "Properties" windows. And there should be a way to do this, IDing the Client name along with the corresponding IP address. The Test command seems like one way to do this, but this limited feature only allows users to enter hard IP addresses.

 

After that, if a password is entered, the Properties should include info on the machine *plus* PC name (not just Retrospect client name)--all the same info that Adding the client would include but without the need to actually Add the client.

[awnews]

After an initial "test" of about 30 Retrospect Clients, I'm in the process of rolling Clients across hundreds of PCs and Macs (post-DHCP conversion, so I can no longer associate a Client with a specific IP). As part of this process and the normal environment, machines are being moved around and renamed & retasked. Based on this:

 

1) You *have* to provide us with a way to rename the client **from the client.** I can't emphasize this enough. Not having this "feature" is like MS Word not being able to print or a browser unable to access web sites... When a machine (or many machines) needs to be renamed I have to write down all the names and then walk across the campus to the server to manually rename them. Or uninstall the client, rename the machine, then reinstall. This is needlessly difficult and error prone (e.g. when changing was/is loops (A->B, B->C, C->A), when more than one client has the same name and I need to sort them out to make them unique, etc.). *PLEASE* provide this "feature" in the next Client version.

 

2) Almost all the time, I want the name of the Retro Client to match the name of the machine and I *can* rename the later at the machine. But the Client rename doesn't automatically happen as machines are renamed (with all OSes? with some OSes?), with the Client retaining the old name. In addition to allowing the Client to be renamed from the machine, I'd suggestion an option to allow the Client name to always match the machine name. In addition to simplifying things, this has the advantage that a *user* renaming a machine would also automatically rename the Retro Client.

 

Putting these two together, this might look like this:

 

( ) Retrospect Client name is [ CN_ROOM2_PC3 ]

(*) Retrospect Client name matches name of machine: ////CN_ROOM8_PC2////

[natew]

Hi

 

I certainly see your point. Client management is less than ideal for what you are doing. Nothing wrong with the way you are doing it of course, Retrospect just isn't really designed to work that way.

 

one suggesstion, could you change the client names before you walk over and change the hostnames? That may make it easier to track.

 

The fundamental concept in Retrospect is that all of the management is centralized and happens from the server. Allowing clients to change passwords and names could make that manangement much more difficult.

 

It also represents a lot of engineering work for the client app. We would have to create away to block access to these features for non-priveleged users. We would also need to set up Retrospect client to queue name and password requests when the Backup server is not running. There is actually quite a bit of stuff that would have to change. Its quite doable but to be completely honest, I'm not sure the demand is there to take time away from other features and fixes.

 

Regardless, I will pass on these items as a feature request as they would indeed be a good addition to the software.

 

Thanks

Nate