[brantb]

Hello!

We have had WinFax 10.02 (5 nodes) working very well for several years, in a Win2000 envrionment. Recently, we had to change the “host” system (old hardware was dying) … and the new system has WinXP SP2.

I’m aware that SP2 causes issues, and I have reviewed the Symantec KB article regarding the adjustments required to the DCOM security etc. I have performed those steps as outlined in the article – that is, I have done them on the host system. I have not done anything on the client systems, since they are still running Win2000 (SP4) – and it is not clear to me that the suggested steps are pertinent to Win2000.

Unfortunately, simply upgrading the client O/S to WinXP is not a viable option at this point, for many reasons … but it is in the plans for the future. Also (as you are no doubt already aware), Symantec does not seem to be providing the 10.03 version/update anymore … and the 10.04 patch/update (which they do still publish) can apparently *only* be applied to 10.03. So, we’re kinda stuck there, too – we have to make 10.02 work (which will suit us just fine).

By the way – the WinXP firewall is not an issue in this case, as it is disabled (it’s not just turned off … the actual service is disabled). Also … the user accounts in this environment are non-Admin (for their own safety, and to help mitigate malware, etc., etc.).

I’ve done a fair amount of research, but so far, I have not had any success in making the Win2000-based WinFax clients connect to the WinXP-based WinFax host.

Any words of wisdom will be greatly appreciated! 🙂

Brant

[Administrator]

You shouldn’t have to make any changes on the Windows 2000 clients at all, only if there is a firewall on the Windows 2000 systems do you require to make an exception rule for “wfxctl32.exe”.

You need to ensure that your clients on Windows 2000 are all using the same version installed on the Windows XP Host. In your setup, They should all be at version 10.02

Since you’ve probably already followed the steps correctly, what I’d suggest is to check for DCOM related problems on the Host. Start Windows XP’s Event Viewer prior to starting WinFax PRO. Then , start WinFax PRO Controller (Make sure Host Sharing is enabled, if it is not, turn it on and restart WinFax) You can tell WinFax is setup as a Host by the yellow controller having a network connection icon. Refresh the Event Viewer (System Log) and check logs for any DCOM Error Messages with a Red “X”
Do you get any errors ? If so, what are they?
More info on Event Viewer usage here: http://support.microsoft.com/kb/308427

[brantb]

Hi,

Yes, there is a desktop firewall (Outpost Pro) on the Win2000 clients – but, there is already a suitable rule in place from the previous set-up. When we replaced the host system, we made sure that the IP address (and even the machine name) was identical to what the old one was. (We first removed the old machine from the domain’s Active Directory, to make sure that there were no problems introducing the new unit [smile].)

Thanks for the tips regarding looking for DCOM errors. When no red flags turned up, I started to really scratch my head. Then, it struck me that there was another test I could perform. I tried faxing (from a client) using an Admin account – and it worked! Ah ha – now I knew I had a security/permissions problem.

I went back and reviewed everything – again. It seems that, for some reason, step 4.8 of the Symantec KB article had not “stuck”. I know I did it, because I have a check-mark beside each of the sub-steps on my printout (and I’m careful about those things). But, alas, the “Remote Access” option was _not_ ticked for the ANONYMOUS LOGON within the Access Permissions on the COM Security tab on the host.

I changed that, and tried again (with a normal, non-Admin account) … and there are encouraging indications of progress, but I’m not out of the woods yet. ???

When trying to fax from a client (non-Admin), I now get the following message:

WinFax PRO is unable to connect to the WinFax PRO Host station called 10.1.2.2. Make sure an account has been created for you on the host station (using the same name/password used to login on your client station).

Hmmm. This environment is part of a domain – where there is a single/central server, which runs Active Directory, MS Exchange, etc. There are ~35 users in the domain – 5 of whom are set up with WinFax on their (Win2000) workstations. The WinFax Host is on a sort of “butler” box which is unattended; it is there specifically to provide the WinFax hosting service and a couple of other similar/centralized services. It is running XP SP2 – it is *not* a full server.

Given that the user accounts already exist in the domain, and that the WinFax Host system is already a member of the domain … I’m not sure how I would go about creating the users accounts on the system itself. Is it really necessary to create local machine accounts on the host which are essentially “duplicates” of the domain accounts? That doesn’t really “smell” right to me. Do the approprite domain user accounts perhaps need to be made members of the local machine Power Users group on the Host? It’s just a thought – and if that’s what it takes to resolve this issue, I would be willing to make that compromise. But, if you’ve run into this issue before, and there is a better or more appropriate solution, that would certainly be fine too.

Any (more) words of wisdom will (still) be greatly apprecaited! 🙂

Brant

[Administrator]

If its working when you log into an Admin account on the Windows 2000 client machine, then your Windows XP SP2 Host settings are correctly set. You shouldn’t have to make any changes to the Host.

If the account logged in is non-admin, and it fails, It sounds like a permissions (policy?) problem on the Windows 2000 PC. Do you disable any DCOM Remote Procedure Call (RPC) Locator Service for non-admin users?

Also, just a note once you’ve performed the Windows XP SP2 security steps for DCOM on the Host, do not change Host settings again on WinFax Host machine (do not click OK at the Host Configuration dialog box) because once you click OK you have to re-do “Section 6: To enable Anonymous Logon users to have remote activation access to the WinFax.Attachment DCOM component”
From our experience, you have to remove (un-do) the ANONYMOUS LOGIN entry, and re-add it as described in Section 6.

If you have to view the settings in the Host’s Configuration dialog box, always click CANCEL to get out of the dialog box. If you change any item, or click OK without changing anything you have to perform the steps again as outlined in Section 6.

[brantb]

I was in over the weekend, to do some more work on this. I did manage to get things working, before I got your reply.

What I ended up doing, was taking a shotgun approach (not my usual style – but, I was really starting to get a bit of pressure to get this resolved). I ended up ticking all of the permissions for the Anonymous Logon (in the COM and DCOM areas), and I also added Athenticated Users – with all permissions ticked. Then, everything worked without a hitch. My hunch is that the Authenticated Users entry made the difference … and if I ever get enough time to go back and do some isolation testing, I will surely check it out (and post back here).

I did notice (before making the above adjustments) that the nature of the misbehaviour seems to depend on exactly how the client was started. If the controller started while in an Admin account, and I subsequently tried to fax from a non-Admin account, I would get one error message (account related). Otherwise, if I rebooted the client system and went directly to a non-Admin account to start up the controller, and tried to fax from that non-Admin account, then I would get a different error message (RPC related).

We don’t have any COM, DCOM, or RPC related policies set on our Win2000 PDC. At least, none that are overtly set – perhaps, there is one with a side-effect. Having said that though, given what finally worked for me, it seems unlikely to be a policy issue.

Thanks for the tip about the Host Configuration issue – that’s a really good thing to know, before it actually happens to me. 😀

Cheers!

Brant

[Administrator]

Good to hear. I agree, its probably the adding of the authenicated users with the appropriate permissions on the Host machine that did it.

Yes. its very common that one in a while something causes a client not to connect to a host, a newly installed firewall for example, and the first thing most people check is the Host configuration at the WinFax Host, confirm the settings, and click OK. Once you do that, then you have the problem where the client won’t connect because the previously modified DCOM security settings no longer apply.

[Author]

Posts