Kromey's questions

I work for a good-sized school district and have just successfully deployed Exchange 2013 and migrated all of our users' mail to the new system over the summer. Been a few bumps along the way, but with school starting up again soon we have a large number of staff now logging in and using the new system for the first time, and unfortunately a small but growing number of them are beginning to encounter the now-dreaded "Critical Error" message when attempting to access their Options:

The full report is thus:

Client Information
------------------
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:39.0) Gecko/20100101 Firefox/39.0
CPU Class: undefined
Platform: Win32
System Language: undefined
User Language: en-US
CookieEnabled: true
-----------------
Exception Details
-----------------
Date: Fri Aug 07 2015 14:38:24 GMT-0800 (Alaskan Standard Time)
Message: Error: Permission denied to access property "frameElement"
Url: https://webmail.example.com/ecp/15.0.1104.5/scripts/common.js
Line: 1

Call Stack
----------
ErrorHandling.$EM@https://webmail.example.com/ecp/15.0.1104.5/scripts/common.js:1:172926
ErrorHandling.showUnhandledException@https://webmail.example.com/ecp/15.0.1104.5/scripts/common.js:1:171997

Detailed Call Stack
-------------------

That's not a typo or omission, the "Detailed Call Stack" really is blank. This happens regardless of browser: I've received reports from users using Firefox, Chrome, Safari, and IE; pretty sure the only reason Opera's not on that list is that no one uses it. Reloading the page (as the message suggests) doesn't help, and the "ok" button is useless. Once the error appears, the user can close and re-open the browser or even go to a completely different browser and get the same results.

This is purely a client-side error: Absolutely nothing relevant shows up in server logs when this occurs.

This seems to me to be obviously the web browser employing its usual anti-XSRF defenses and OWA handling that error "nicely". What I've been unable to figure out for 4 weeks running now is why this is happening.

1. Users are directed to webmail.example.com to access OWA.
2. Every single virtual directory on every single server is configured to use webmail.example.com as both the external and internal hostname (or host part of the external/internal URL).
3. Looking at the Network panel for a web browser exhibiting this error, I see nothing but requests for resources on webmail.example.com -- there's simply no other host involved that I can see.

What's doubly strange is that when this occurs, most users can clear it up by following this procedure:

1. Sign out of Outlook Web App
2. Clear the browser's cache and "offline data"/"offline websites"/etc (cache alone is not sufficient)
3. Close the browser completely​
4. Reopen the browser and sign back in to OWA

It's only a temporary workaround, however, as the issue returns shortly.

How can I figure out what's causing this error, and more to the point how can I fix it?

In our organization we use room calendars to track overtime and leave, which gets tallied up every two weeks for payroll. We've just recently migrated from Zimbra to Exchange 2013, and have hit a snag with this workflow.

Often -- especially if someone is out sick -- people will not put their leave or overtime on the calendar right away, much less ahead of time. This means they're putting their leave on retroactively, usually when the reminder email to do so is sent out.

Still new to Exchange, we were surprised this week to discover that resources automatically reject meeting requests in the past. That's fine, that's probably what we want for all the "real" rooms we have, but it's not what we want for these calendars.

How can we turn this feature off for these calendars? I've dug through every calendar-related PowerShell command I could find to no avail. Making everyone an editor on these calendars is not an option; they need to send invites to the calendar. Is our only option to adopt a different workflow?

Edit: Here's the full calendar processing configuration for one of the relevant calendars:

PS > Get-CalendarProcessing ins.calendar | fl

AutomateProcessing                  : AutoAccept
AllowConflicts                      : True
BookingWindowInDays                 : 730
MaximumDurationInMinutes            : 0
AllowRecurringMeetings              : True
EnforceSchedulingHorizon            : False
ScheduleOnlyDuringWorkHours         : False
ConflictPercentageAllowed           : 0
MaximumConflictInstances            : 0
ForwardRequestsToDelegates          : True
DeleteAttachments                   : True
DeleteComments                      : True
RemovePrivateProperty               : True
DeleteSubject                       : False
AddOrganizerToSubject               : False
DeleteNonCalendarItems              : True
TentativePendingApproval            : True
EnableResponseDetails               : True
OrganizerInfo                       : True
ResourceDelegates                   : {}
RequestOutOfPolicy                  : {}
AllRequestOutOfPolicy               : False
BookInPolicy                        : {}
AllBookInPolicy                     : True
RequestInPolicy                     : {}
AllRequestInPolicy                  : False
AddAdditionalResponse               : False
AdditionalResponse                  : 
RemoveOldMeetingMessages            : True
AddNewRequestsTentatively           : True
ProcessExternalMeetingMessages      : False
RemoveForwardedMeetingNotifications : False
MailboxOwnerId                      : domain/Resources/ins.calendar
Identity                            : domain/Resources/ins.calendar
IsValid                             : True
ObjectState                         : Changed

Our notification system alerted me this morning that one of the virtual servers in a small cluster was running out of space on one of its disks. To head off the same on the other servers and other disks, I hopped into vSphere and expanded the size of all disks on all the servers, then hopped into Server Manager to extend each volume.

For 3 of the servers, this worked like a charm, but on one server, one disk failed to extend -- the error in Server Manager was simply "Extend Failed". Logging into that server and opening Disk Management, I can see that the partition has been extended to 120 GB as it should, but the volume still has only an 80 GB capacity:

I'm less concerned with how this happened than I am with how to fix it now that it has. I can't extend it because "Extend Volume" thinks it's 120 GB, yet the volume itself thinks it is only 80 GB. Worst-case scenario I can delete and re-create the volume, but as it would take time to rebuild the data I'd prefer to avoid that option if at all possible.

How do I get my E: drive to realize that it really does have 120 GB available to it, not merely 80 GB?

Recently we've had a spate of "spear-phishing" attacks that many of our users have fallen for, and as a result our automated scripts are running at full steam locking accounts that have been compromised and are sending out spam.

This morning I spent 2 hours dealing with one in particular that seemed to still be sending mail even after the account had been locked and then authentication entirely (and deliberately) broken altogether. Turns out the problem was a huge backlog of deferred messages that Postfix was diligently trying to re-send. As a result I will be updating our script to purge the queues of accounts that it locks to hopefully cut down on the amount of spam that gets sent out before they're detected.

What I'd like to do now is to configure Postfix to automatically defer messages based on certain criteria, such as the number of intended recipients. If it's a legit message it will go out after a delay, but if the account is seen to be sending spam we've got a better chance of catching and deleting it before it gets sent.

Is there a way that I can configure Postfix to defer any message that arrives and exceeds a certain threshold of intended recipients (or other criteria)?

I have a new Exchange 2013 environment running on Windows 2013 R2 with 2x Edge and 4x CAS/Mailbox servers deployed. It is deployed in a resource forest, with proper trust relationships established to the primary forest. OWA, ActiveSync, and IMAP all work great.

For those clients that don't/won't work with ActiveSync, I of course need IMAP and SMTP (we're consciously giving a flat "no" to POP). IMAP is working fine; SMTP is not.

The default receive connector Client Frontend is configured to listen on port 587. When I disable TLS in e.g. Mac Mail (behavior's virtually identical regardless of client), I'm able to login only with users in the resource forest -- I cannot authenticate users in the primary forest. If I enable TLS (which is what I want, and what the settings seem to indicate), I can't connect at all.

Interestingly, the Client Proxy default receive connector (on port 465) does work, with TLS enabled and authenticating primary forest users. This tells me that the SSL certificate is fine, as well as the trust is functioning.

I can't figure out why the Client Frontend connector will not let me connect over TLS. When I use Telnet, I get the following introduction:

Trying x.x.x.86...
Connected to excmb1.example.com.
Escape character is '^]'.
220 example.com Microsoft ESMTP MAIL Service ready at Wed, 6 Aug 2014 15:51:27 -0800
ehlo
250-example.com Hello [x.x.x.155]
250-SIZE 36700160
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250 CHUNKING
quit
221 2.0.0 Service closing transmission channel
Connection closed by foreign host.

I can't help but notice the lack of the "250-STARTTLS" line there -- it is present when I Telnet to port 465.

Using the EMC and the Get-ReceiveConnector cmdlet, the two receive connectors are essentially identical. So why won't the one on 587 -- the one that clients are supposed to use for SMTP -- not work over TLS nor authenticate trusted domain users? Why does one receive connector -- the one that's supposed to just be for the Exchange servers to talk to each other -- work, while a seemingly-identical one not?

I have a server that is aggregating logs from various other servers. It mostly works great, however from time-to-time (right after a reboot, but not all reboots) it will decide that various UDP "connections" are in some weird state, and reject incoming packets.

Thing is, that doesn't make sense, because there are no "connections" when dealing with UDP!

Here's an example of what shows up in my firewall logs:

Shorewall:loc2fw:REJECT:IN=eth0 OUT= MAC=/*snip*/ SRC=10.x.x.4 DST=10.y.y.14 LEN=159 TOS=0x00 PREC=0x00 TTL=254 ID=37407 PROTO=UDP SPT=514 DPT=514 LEN=139

After running the command sudo conntrack -D -p udp to clear all UDP "connections" from conntrack, here's a log showing an incoming message from the same host:

Shorewall:loc_dnat:REDIRECT:IN=eth0 OUT= MAC=/*snip*/ SRC=10.x.x.4 DST=10.y.y.14 LEN=201 TOS=0x00 PREC=0x00 TTL=254 ID=50542 PROTO=UDP SPT=514 DPT=514 LEN=181

And here's what shows up in conntrack for this host before I ran the -D command:

udp      17 29 src=10.x.x.4 dst=10.y.y.14 sport=514 dport=514 [UNREPLIED] src=10.y.y.14 dst=10.x.x.4 sport=514 dport=514 mark=0 use=1

Here's the relevant bits from my Shorewall configuration for this port:

#ACTION         SOURCE          DEST            PROTO   DPT
SECTION NEW
REDIRECT:info   loc             5000            tcp,udp 514
ACCEPT:info     loc             $FW             tcp,udp 5000

And for completeness' sake, here's the resultant chain in iptables (this is after the conntrack -D -p udp command was run and the firewall had been properly accepting packets for a while):

Chain loc2fw (1 references)
 pkts bytes target     prot opt in     out     source               destination         
16328 1648K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
 6428  386K ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 /* Ping */
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 /* SSH */
   18  1080 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 /* HTTP */
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5000 ctorigdstport 514
  12M 6677M ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5000 ctorigdstport 514
    0     0 ~log0      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto]  tcp dpt:5000
    0     0 ~log0      udp  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto]  udp dpt:5000
   52  3088 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:9200
 126M   32G Reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
 126M   32G LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 6 prefix "Shorewall:loc2fw:REJECT:"
 126M   32G reject     all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto]

As you can see, I'm using a REDIRECT rule to accept connections coming in on port 514 and send them instead to port 5000, where my log aggregator listens (was easier to accomplish this in the firewall than to jump through the hoops to allow an unprivileged user to open a privileged port).

I can't understand why UDP "connections" seem to get into this strange state where they get rejected by the default policy; I say this because they show up quite clearly in conntrack, and deleting them from there seems to "reset" everything and let the messages flow into my log aggregator again. At this point the only alternative I see is setting up cron to run my conntrack command shortly after reboot, but I'd much rather understand why this is happening and fix the cause rather than just implement this workaround.

In a testing environment, I'm currently being held up from testing some things that need to be deployed soon (actually already, but you know how deadlines go...) because Windows refuses to trust the self-signed certificate we have in our isolated testing environment. While I could just side-step the issue with the "real" certificate and some DNS tricks, for security/compartmentalization reasons I don't have said certificate.

I am attempting to connect to a Linux-based email server called Zimbra; it is using an auto-generated self-signed OpenSSL certificate. While the pages Google has turned up specifically refer to IIS websites with IIS self-signed certificates, I don't think the method of generating it actually matters.

According to instructions I found here and here, this should be a simple matter of installing the certificate into the local computer's Trusted Root Certification Authority store. Which I've done, as well as manually copying the certificate and importing it directly via the MMC snap-in. Log-outs and reboots don't change anything.

Here's the certificate error I get every time:

And here's the Certification Path (spoiler: it's just the certificate itself):

Finally, here's the certificate safely tucked away in the local computer's certificate store, exactly as the instructions I've found say they should be:

These instructions specifically reference Vista (well, the second doesn't mention OS) and IIS, while I'm using Server 2012 R2 connecting to a Linux-based server; there are some differences in the import wizard (such as mine has the option to import for current user or local system, although I've tried both), so maybe there's something different that I have to do here? A setting somewhere I've not found that has to be changed to make it really truly trust the certificate I've already told it to trust?

What's the correct way to make Windows Server 2012 R2 trust a self-signed certificate?

I'm trying to use Shorewall's REDIRECT action to intercept traffic destined for the firewall's port 514 (TCP and UDP) to port 5000 (also TCP and UDP), while also allowing direct traffic to the latter port as well. (The reasons aren't important, but the short version is that we're running a log aggregator as an unprivileged user, but the daemon doesn't support dropping root privileges so it therefore cannot listen on the privileged ports; at the same time we have a lot of older syslog implementations that don't allow sending to alternative ports.)

In addition to the firewall itself, there are 3 zones defined: loc (10.0.0.0/8), dmz (172.16.0.0/16), and net (everything else); the latter exists primarily to deny/drop everything from "untrusted" networks.

The relevant rules look like this:

#ACTION         SOURCE          DEST            PROTO   DEST
#                                                       PORT
SECTION NEW
REDIRECT:info   loc             5000            tcp,udp 514
REDIRECT:info   dmz             5000            tcp,udp 514
ACCEPT:info     loc             $FW             tcp,udp 5000
ACCEPT:info     dmz             $FW             tcp,udp 5000

So far so good. (There are other rules, such as allowing SSH and HTTP connections, but these are the only ones relevant to ports 514 or 5000.) Default policy is REJECT for loc and dmz, and DROP for net.

The problem is that I have many, many instances of hosts being rejected, while neighboring hosts in the same network are being redirected and accepted. For example, 172.16.0.194 is stuffing messages into our aggregator just as fast as it can, but 172.16.0.166 is having every packet rejected. Similarly, 10.140.88.150 is being accepted, while 10.192.253.4 is being rejected. Here's sample syslog messages for the latter pair:

Shorewall:loc_dnat:REDIRECT:IN=eth0 OUT= MAC=/*anon*/:08:00 SRC=10.140.88.150 DST=10.1.25.14 LEN=134 TOS=0x00 PREC=0x00 TTL=253 ID=9092 PROTO=UDP SPT=62162 DPT=514 LEN=114
Shorewall:loc2fw:REJECT:IN=eth0 OUT= MAC=/*anon*/:08:00 SRC=10.192.253.4 DST=10.1.25.14 LEN=164 TOS=0x00 PREC=0x00 TTL=254 ID=58464 PROTO=UDP SPT=514 DPT=514 LEN=144

What I find interesting is that there's very few instances of successful REDIRECTs in my log (e.g. only 1 for this host), despite the hosts that are successful sending thousands and thousands of messages, whereas there seems to be a REJECT line for every single message a rejected host is sending. It's also interesting that for many of the hosts now being rejected, they were being redirected and accepted, up until a firewall restart when we tried to add a new rule (said rule has since been removed, but we're still having the same issues). All of the current messages are coming in on UDP, but the rules need to work for both protocols.

(Also interesting is that, using tcpdump, I can see ICMP "port unreachable" responses being sent out to some rejected hosts, but not to others. I have no idea what, if anything, that means.)

My theory is that the messages from the rejected hosts are being seen for some reason as part of an ESTABLISHED or RELATED connection by iptables and therefore don't get matched to anything in SECTION NEW; however, this is the only section where REDIRECT or DNAT rules can be put, so if that's the problem I have no idea how to resolve it. (I also have no idea how to confirm or refute this theory.)

I've tried using DNAT (with $FW::5000 in the DEST column) instead of REDIRECT, however the results were identical. I also tried adding ACCEPT rules for port 514, but that had no effect on who did or did not get picked up by the REDIRECT rules.

How do I need to configure Shorewall so as to properly redirect all connections to a given port from the specified networks (zones), rather than just seemingly random hosts therein?

As part of a planned migration to Exchange 2013 from a third-party e-mail system, we will be interoperating side-by-side with the existing system for some time, and want to share free/busy data between them. However, Exchange 2013 makes this difficult by prefixing the user name with a GUID in the LegacyExchangeDn attribute in AD. We'd like to turn this off to make managing the migration and interoperability easier on us, and the cmdlet Set-OrganizationConfig purports to let us do precisely that.

However, when I actually try and run it:

[PS] C:\Windows\system32>Set-OrganizationConfig -IsGuidPrefixedLegacyDnDisabled $true
A parameter cannot be found that matches parameter name 'IsGuidPrefixedLegacyDnDisabled'.
    + CategoryInfo          : InvalidArgument: (:) [Set-OrganizationConfig], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Set-OrganizationConfig
    + PSComputerName        : exchange.domain.local

Technet and even the Get-Help cmdlet include this parameter, but the cmdlet itself doesn't seem to recognize it. Am I doing this wrong, or is this a bug? If the latter, is there a workaround?

In advance of a brand new Exchange 2013 deployment to replace a third-party e-mail system, I have a lab network with a clone of our AD environment so I can test various scenarios. In this testing, I've run across repeated instances of this error:

The object domain.local/Staff/aduser has been corrupted, and it's in an inconsistent state. The following validation errors happened:

The property value is invalid. The value can't contain leading or trailing whitespace.

There are multiple instances of this same error for seemingly random AD objects. In this case, I was trying to create a Mail User using the ECP. Searching has lead me to various different AD attributes where others have had this issue, but in my case all of those seem to be fine. We do have some custom extensions to our AD schema, and there are several now-ancient Perl scripts in charge of keeping AD updated from various other sources, so any of a very long list of fields could be the culprit.

What can I do to find out which field(s) Exchange is complaining about? Unfortunately I'm a Linux guru, so my knowledge of AD tools is very limited. As a corollary, is there a way to quickly/easily check my entire AD structure for similar issues?

I have a Windows XP Pro server running Apache 2.2, which is configured with an Alias /p that points to a UNC network path (//server/projects). Apache runs under the user Apache, which (as part of some previous troubleshooting) is a member of the Administrators group. I happen to have written up a blog post here that details the setup if you want more detail.

This Apache server runs a PHP application that, among other things, needs to access the server's serial ports (if you must know, it's a POS application, and yes I'm fully aware that a web app is not the ideal approach here -- wasn't my call). This works just fine from PHP scripts running off of the C drive, but scripts that live on the network server do not appear to have access to the server's hardware.

Accessing the serial ports is done like so:

<?php
$fh = fopen('com3', 'w+');
fwrite($fh, $data_to_send);

Again, works just fine for files that live on the C drive, but identical files on the UNC path don't work.

I need to find a solution that will allow these PHP scripts the same access to the hardware whether they're on the C drive or pulled from a network share.

Additional information:

• This is a VM in VirtualBox; the network share is in fact a VirtualBox Shared Folder, which is implemented as a SMB network share. Full read/write access, and works for everything except this one thing.
• Security of the server isn't a concern -- this is a dev/testing setup that is behind 3 distinct firewalls and NAT layers (a private LAN within a private LAN within a private LAN) with absolutely no access to it through any of them.
• PHP is configured as CGI rather than an Apache module (not something I can change, since this is how this app is deployed); nonetheless, it does run under the Apache user as well.

This is a strange one that has plagued me for a while now. When logging in to the second instance of SQL Server 2008 on one of our database servers, we get a timeout error:

Cannot connect to servername\mssqlserver2.

Additional information:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. (Microsoft SQL Server)")

(This is the error message when trying to connect with Microsoft SQL Server Management Studio; other tools experience the same error, but of course say it in different ways.)

Immediately re-attempting to log in works just fine, so whatever the cause it's ephemeral! This happens regardless of user or authentication type (both Windows and SQL Server authentication methods are supported on this instance). What's even weirder, though, is that the first instance on this server has never once demonstrated this problem.

Server is a Windows Server 2008 R2 virtual server, hosted in Microsoft Hyper-V (host is likewise Server 2008 R2). The server has 2GB of RAM, and seems to regularly be using 90% of that -- could low memory be the cause of this issue? I could see this second instance -- which is not used very often yet -- being swapped out to disk, and then taking too long to load back into memory to respond in time to the connection request, but I'd rather have more than just my own hunch before I go scheduling a downtime for this server (the first instance is used regularly) and then just throwing extra resources at it in the blind hope that the problem goes away.

I have an nginx server serving up nearly half a dozen different websites. It's running on a Linode that just got IPv6 native support (Dallas data center), and I'm trying to configure most of my sites for dual-stack operation. I got the first one up and running using an IPv6-only subdomain like so:

server {
    listen [::]:80 ipv6only=on;
    listen 80;

    server_name example.com ipv6.example.com;

    root /var/www/example.com/htdocs;

    #More stuff, including PHP, WordPress
}

This works great -- example.com is IPv4-only (for now), and ipv6.example.com is IPv6-only (primarily there for testing purposes). I can ping6 ipv6.example.com, and even wget ipv6.example.com without breaking a sweat -- this much was pleasantly pain-free (after finding the "gotcha" with the way nginx binds virtual hosts, necessitating the ipv6only=on argument and the dual listen directives).

However, I'm now trying to expand this to support my other domains, starting with static.example.com; when I take the same approach as above, though (the dual listen directives, including the ipv6only=on argument), I get the following error when restarting nginx:

* Starting Nginx Server...
nginx: [emerg] a duplicate listen options for [::]:80 in /etc/nginx/sites-enabled/example.com.conf:3

It seems that perhaps nginx's method of binding for IPv6 doesn't permit name-based virtual hosts? Will I have to get additional IPv6 addresses from my host (not a problem) and use IP-based virtual hosting on IPv6 with named-based virtual hosting over IPv4? Or am I missing a solution that will allow my configurations to remain consistent on both stacks?

I was hoping to have my site fully on the IPv6 stack in time for World IPv6 Day, but unless I can clear this up quickly I may not be ready. Not a big deal from any practical standpoint -- none of my sites qualify as a "major organization" by any stretch of the imagination -- but help me save my geek cred!

Edited to add:

Thanks to the answer from @kolbyjack, I have a fully functional dual-stack web server now. Just for clarity's sake, I'm editing in the solution he gave me so everyone can see clearly what the answer is.

My default catchall vhost has the following listen directives:

listen 80 default_server;
listen 8080 default_server;
listen [::]:80 default_server ipv6only=on;
listen [::]:8080 default_server ipv6only=on;

I don't know if the order matters, but there it is. Then, each additional vhost has the following listen directives:

listen 80;
listen [::]:80;

(Or 8080 for the one that listens on that port instead.) The important part here appears to be the total lack of any additional arguments on all but the default vhost's listen directives -- i.e. no repetition of ipv6only=on.

Again, much thanks to @kolbyjack for the solution here!

Yesterday I spent 4 hours trying to get my network's DHCP/DNS/SMB server back online. Long story short, it took numerous wildly frustrated shots in the dark (no DNS = no internet resources for help) and no fewer than half a dozen reboots to finally restore my server to functioning order.

What precipitated this was configuring and enabling my server's second Ethernet port in /etc/network/interfaces. That's when it all hit the fan. I've finally gotten eth1 disabled again and eth0 is working as before, but this isn't the state I want this server to be in.

eth0 and eth1 are both gigabit ports built into the motherboard (an ASUS something-or-other), and previously they were both bonded together (round-robin, I think); however, the server's been completely reformatted and re-installed since then (hard drive failure precipitated that), so I would think that anything the bonding driver had configured would be dead and gone.

While the server was offline, ifconfig seemed to be showing that it was receiving packets just fine, but every single outgoing packet was being dropped. (I should have saved the output from ifconfig during the issue, but the 'TX' line showed "packets:0" and "dropped:123"; also "errors:0 ... overrun:0 carrier:0".)

eth0 is configured with a static IP; I did the same for eth1. Here is /etc/network/interfaces:

root@odin:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
    address 10.12.0.50
    netmask 255.0.0.0
    gateway 10.12.0.2

# The secondary network interface
# Commented out now because this was the only way I could get it to work again
#auto eth1
#iface eth1 inet static
#   address 10.12.0.51
#   netmask 255.0.0.0
#   gateway 10.12.0.2

ethtool shows:

root@odin:~# ethtool eth0
Settings for eth0:
    Supported ports: [ MII ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: 1000Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 1
    Transceiver: external
    Auto-negotiation: on
    Supports Wake-on: g
    Wake-on: d
    Link detected: yes

The output for eth1 is identical, except that it shows "Link detected: no" because it's disabled currently; "Link detected" was always "yes" for either interface when it was supposedly enabled, even when eth0 was apparently unable to send any packets.

/var/log/syslog shows numerous entries like this:

May 11 21:55:08 odin kernel: [  797.050022] forcedeth 0000:00:08.0: eth0: Got tx_timeout. irq: 00000020·
May 11 21:55:08 odin kernel: [  797.050026] forcedeth 0000:00:08.0: eth0: Ring at 112804000·
May 11 21:55:08 odin kernel: [  797.050029] forcedeth 0000:00:08.0: eth0: Dumping tx registers·
May 11 21:55:08 odin kernel: [  797.050035] forcedeth 0000:00:08.0: eth0:   0: 00000020 000000df 00000003 0001000d 00000000 00000000 00000000 00000000·
[bunch more lines like this one, though none reference eth1]

Also in syslog are countless repetitions of the following lines:

May 11 21:54:42 odin kernel: [  770.480861] martian source 10.12.0.50 from 10.42.0.206, on dev eth1·
May 11 21:54:42 odin kernel: [  770.480865] ll header: ff:ff:ff:ff:ff:ff:00:1e:65:d6:6c:6a:08:06·
May 11 21:54:42 odin kernel: [  770.987932] martian source 10.12.0.51 from 10.12.0.2, on dev eth1·
May 11 21:54:42 odin kernel: [  770.987937] ll header: ff:ff:ff:ff:ff:ff:00:13:46:ed:e2:4a:08:06

The "from" address is different, but it's always eth1 and always "source" 10.12.0.50 or .51. That "martian" thing reminded me that I am running Shorewall, but turning it off (and verifying that iptables -L showed nothing but accepting everything from/to anywhere) had no effect whatsoever. I'm not even sure why eth1 would be seeing traffic intended for eth0's address in the first place, given that they're connected to a switch that (in my understanding, anyway) would only send packets to their intended destinations. (It is an unmanaged gigabit switch, Linksys I think.)

I don't even know how to begin to diagnose or troubleshoot what went wrong here. Frankly, I'm afraid to try to start eth1 again, especially since I don't even know what finally fixed the problem so I don't know that I could get it reverted again to its current state. What can I do to figure out what happened, and to fix it so that I can again turn on eth1 without blowing up the server's networking again? Could the hardware still be mis-configured from the previous system install using the bonding driver? How could I determine that and, if that's the case, fix it?

Both ports worked perfectly independently on the previous install before I set up bonding, and I had no issues at all during that time. I re-installed the system about 4-ish weeks ago, and eth1 has been disabled since then (Ubuntu detected it during the installation routine, but I of course chose eth0 as my "primary" interface during the install and Ubuntu apparently made no effort to configure eth1 after that).

I'm using smartd to monitor the S.M.A.R.T. health of the internal hard drives on my file server and alert me to signs of impending doom. I would also like to monitor the external eSATA hard drives I'll be using with it, but I'm not sure how to overcome these obstacles:

1. Being an external drive used for off-site backup, it may or may not be present. How can I make smartd not "freak out" and spam my e-mail inbox when the drive "disappears"? (Note: I haven't tested this yet, but I'm assuming smartd will assume a catastrophic failure of the drive if it suddenly can't be found.)
2. For the same reason as above, the drives won't always be e.g. /dev/sdf (in fact, once I remove the USB HDD that's currently connected, the next time I connect one of them it will be /dev/sdg!), but it's my understanding that by-UUID and friends reference partitions, whereas I need to reference devices for smartd. How can I reliably point toward these external drives without having to manually update the /dev/sd* reference each time it's plugged in?

Using DEVICESCAN in the config file seems the obvious choice, since I am using identical configurations for all my drives anyway, but it's my understanding that smartd only scans devices when it starts up, and I'd rather avoid having to restart the daemon every time I plug in one of the drives (unless this is the most elegant solution to the problem).

Our users are reporting a really weird issue. Using Microsoft Exchange 2007 OWA, when they are typing out a new e-mail, the font size will be what they have selected. However, as soon as they hit the Enter key, subsequent text that they type is suddenly and inexplicably at a smaller font size.

This is made worse (from a troubleshooting standpoint) in that it is intermittent, and only a few users have reported having the problem at all; I've so far been completely unable to reproduce the issue. Has anyone seen this kind of issue before? Or can anyone point me toward good troubleshooting steps to try and resolve this?

Update: I just found this Microsoft KB article that describes nearly-identical symptoms. Unfortunately, this one pertains to Exchange 2003, and following their description of the issue I couldn't replicate it. Still, maybe it will help someone else better understand what's going on, or help point someone (maybe even me!) toward the solution.

Update 2: Now I have found this MS KB article, which does in fact apply to Exchange 2007. However, I cannot replicate the issue as they describe, and I'm 99% sure that Update Rollup 2 for Exchange Server 2007 Service Pack 2 has been applied to our server anyway (reinforced by the fact that I cannot replicate what's described here).