Open Other User's Folder grayed out on EVERY client

[jedwards]

Greetings,

Suddenly - all clients are unable to access other user's folders. Click File | Open and on every workstation 'Open Other User's Folder' is grayed out in Outlook.

I did
/opt/scalix/bin/omshut
/opt/scalix/bin/omrc

No Change.

Then warm booted the scalix server

Can't find any info on this.

Jim Edwards

[ScalixSupport]

Is this an enterprise server as opposed to a community edition server?

If enterprise, do you have a proper license? If you run

omstat -a

is the Licence Monitor Daemon started?

Thanks,
Don

[jedwards]

Yes, it's enterprise, and yes, it's properly licensed.

omstat -a reveals that the License Monitoring Daemon is started with a status of NON-STOP

However, out of 47 workstations we have found that three do not exhibit this problem. Up to date virus scans reveal nothing..

They're running Scalix 9.4.2 Enterprise


From /proc/meminfo

total: used: free: shared: buffers: cached:
Mem: 514478080 507604992 6873088 0 52654080 156647424
Swap: 1077501952 19873792 1057628160
MemTotal: 502420 kB
MemFree: 6712 kB
MemShared: 0 kB
Buffers: 51420 kB
Cached: 140716 kB
SwapCached: 12260 kB
Active: 373876 kB
ActiveAnon: 264624 kB
ActiveCache: 109252 kB
Inact_dirty: 70176 kB
Inact_laundry: 11836 kB
Inact_clean: 9480 kB
Inact_target: 93072 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 502420 kB
LowFree: 6712 kB
SwapTotal: 1052248 kB
SwapFree: 1032840 kB
CommitLimit: 1303456 kB


Df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda3 9.7G 6.9G 2.3G 76% /
/dev/sda1 99M 15M 79M 16% /boot
none 246M 0 246M 0% /dev/shm
/dev/sda5 26G 3.4G 22G 14% /var

top:

10:17:22 up 12:16, 3 users, load average: 0.01, 0.03, 0.01
232 processes: 230 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 0.0% 0.0% 0.1% 0.0% 0.0% 0.3% 99.4%
Mem: 502420k av, 494064k used, 8356k free, 0k shrd, 51484k buff
373184k actv, 69088k in_d, 7792k in_c
Swap: 1052248k av, 19408k used, 1032840k free 138096k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
16830 root 15 0 1288 1288 896 R 0.1 0.2 0:00 0 top
1 root 15 0 500 500 440 S 0.0 0.0 0:04 0 init
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 keventd
3 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kapmd
4 root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd/0
7 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 bdflush
5 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kswapd
6 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kscand
8 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kupdated
9 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd
17 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 scsi_eh_0
18 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 scsi_eh_1
21 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kjournald
80 root 23 0 0 0 0 SW 0.0 0.0 0:00 0 khubd
910 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kjournald
1003 root 15 0 0 0 0 SW 0.0 0.0 0:01 0 kjournald
3143 root 15 0 316 316 232 S 0.0 0.0 0:00 0 syslogd
3147 root 15 0 136 136 72 S 0.0 0.0 0:00 0 klogd
3166 rpc 25 0 188 188 116 S 0.0 0.0 0:00 0 portmap
3178 root 15 0 176 176 116 S 0.0 0.0 0:00 0 mdadm
3219 root 15 0 628 628 380 S 0.0 0.1 0:00 0 sshd
3235 root 25 0 472 472 360 S 0.0 0.0 0:00 0 xinetd
3251 ntp 15 0 2572 2572 2192 S 0.0 0.5 0:00 0 ntpd
3261 clamav 25 0 8644 8644 40 S 0.0 1.7 0:00 0 clamd
3271 clamav 15 0 9388 9388 568 S 0.0 1.8 0:00 0 clamav-milter
3272 clamav 15 0 9388 9388 568 S 0.0 1.8 0:00 0 clamav-milter
3273 clamav 25 0 9388 9388 568 S 0.0 1.8 0:00 0 clamav-milter
3378 root 15 0 624 624 356 S 0.0 0.1 0:00 0 spamass-milter
3382 root 25 0 624 624 356 S 0.0 0.1 0:00 0 spamass-milter
3458 scalix 15 0 3820 3820 148 S 0.0 0.7 0:00 0 omlicmon
3460 scalix 15 0 916 916 264 S 0.0 0.1 0:00 0 omsessd
3463 scalix 15 0 4088 4088 92 S 0.0 0.8 0:00 0 omctmon
3468 scalix 15 0 13496 13M 9500 S 0.0 2.6 0:00 0 omsmdm
3471 scalix 15 0 1000 1000 308 S 0.0 0.1 0:00 0 notif.mon
3476 scalix 15 0 972 972 252 S 0.0 0.1 0:00 0 queue.manager
3480 scalix 15 0 1016 1016 372 S 0.0 0.2 0:00 0 idel.server

All help appreciated

Jim Edwards

[jedwards]

Update -

I jumped the gun - This doesn't look like server. I'm in the wrong thread. Perhaps admin can move this to another subject. However it's resolved.

The problem does not follow the user, but is the same for anyone who logs in on the workstations exhibiting this behaviour. Since it seemed to be the workstation, I was thinking it's in the machine portion of the registry. If I delete the entire directory C:\Documents and Settings\happyuser as well as the roaming profile on the production server, the problem remains.

If I go to a workstation that didn't have this problem and log in as a user that had this problem on another workstation it worked fine.

I uninstalled Scalix Connect and reinstalled. Problem solved. Since I couldn't find any reference to this issue, and response was sluggish (no one saw this before, probably) I believe it to be rare. However, why did this happen to my customer on so many workstations? Nothing remarkable, that I recall, took place to cause this.

As far as the Scalix server is concerned: They've ran it for a month now with heavy useage and it's been a rock. Of course much of the horsepower is Sendmail, which is overly complicated, but we're mostly happy with this system. We want to recommend it to other customers that insist on using Lookout - err, I mean Outlook.

[florian]

Of course much of the horsepower is Sendmail

out of curiosity, what draws you to this conclusion?

I do agree that sendmail setup is somewhat complex, but Scalix doesn't use it all that much. The only purpose sendmail has within our system is to queue and deliver outbound messages to internet recipients. No internal mail passes through sendmail, incoming mails doesn't by default and sendmail never touches the message store and user's mailboxes. The one exception to this is the integration of SpamAssassin or other Anti-Spam tools right on the Scalix server (where many users actually do this on a permeter system in the DMZ) where incoming internet email is also passed through sendmail so that sendmail's milter interface can be used to route the messages through SpamAssassin, Amavis or MailWasher, to be then again passed over to Scalix's own service router for final delivery into the users mailbox. Again, this only happens if you explicitly turn it on (SMTPFILTER=TRUE option in smtpd.cfg).

Therefore, I believe it is fair to say that the stability of the overall mailserver is due to the architecture of Scalix message store, the directory and message routing system; we specifically keep those three core elements closely tied together to allow for what we're doing; as this is also the very part we inherited from Scalix' predecessor product, HP OpenMail, this is what seems to set us apart from competitors and other solutions who often rely on a mix of technologies for their core message handling functionality and suffer from integration pain as a result.

Thoughts appreciated,
Florian