Martin's questions

I have a virtual machine running Windows Server 2019, which is a terminal server with many network interfaces. It is actually a trunk, which is being configured for many vlan interfaces, leading to this many interfaces - but this shouldn't matter to my question. Now, coming to the strange part:

PS C:\Users\XXXX> netstat -n | findstr "192.168.4.80:445"
  TCP    10.0.200.90:49531      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49532      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49533      192.168.4.80:445       ESTABLISHED
  TCP    10.0.200.90:49534      192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49528     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49529     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:49530     192.168.4.80:445       ESTABLISHED
  TCP    192.168.4.90:55959     192.168.4.80:445       ESTABLISHED

Both interfaces in question here are configured with a /24 netmask - and the 10.0.200.90/24 interface holds the default gateway. The routing table is quite large, as there are many interfaces, but there is no conflicting route for the 192.168.4.0/24 subnet. Here are the relevant parts of it:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     10.0.200.250      10.0.200.90    271
       10.0.200.0    255.255.255.0         On-link       10.0.200.90    271
      10.0.200.90  255.255.255.255         On-link       10.0.200.90    271
     10.0.200.255  255.255.255.255         On-link       10.0.200.90    271
      192.168.4.0    255.255.255.0         On-link      192.168.4.90    271
     192.168.4.90  255.255.255.255         On-link      192.168.4.90    271
    192.168.4.255  255.255.255.255         On-link      192.168.4.90    271
===========================================================================

How is it possible that some connections are being sent via the default gateway, and some connections take the proper interface route? I noticed this on the firewall (the default gateway), inside the packet filter logging, so this is not just a display issue, some packets really are being sent over the default gateway - And I checked via the resource monitor, the connections belong to PID 4 (System), which is most likely the mapped network drives.

For all what I know about routing, the metric is only taken into account if there are two routes with the same subnet - in such a case, the route with the lower metric would win. But the default gateway route should never win over a interface route, no matter what metric is configured - correct?

My first thought was that this must be a bug inside windows - maybe a race condition between the process bringing the interface up and the process mapping the network drive. But this is pure speculation, I was hoping someone could enlighten me with a deeper insight...

A small company I am working for has a self-hosted Exchange Server 2010 running, and my job is to migrate this server to an Exchange server 2016, since the old one is out of support for quite a while now.

I know that Exchange 2016 and 2010 can co-exist, and since we cannot afford to loose our emails, I did some testing first. I created a dummy user on the old exchange server, created a migrate job and tried to access it (But the goal is to shutdown the old server after migration has been completed).

Mailflow (sending/receiving from/to external/internal emails - everything works!) is not the problem.

But I cannot get the outlook (2010) clients to work. Please note that we are using Outlook only internal - on a machine which is domain-joined, external access is (currently) not necessary. Whenever I add the dummy account to my outlook, everything works as it should - but as soon as I close outlook and open it again, Outlook cannot access the information store anymore. Accessing the dummy mail via the internal URL https://ex2016.domain.local/owa/ works perfectly.

When I check the connection status right after adding the dummy email account, it shows those mapi over http connections (as far as I know, this is the default access method since exchange 2013). I have executed the autodiscover test, it was successful.

There is a certificate warning, since currently this is the self-signed certificate from the installation. But I also tried replacing this with a certificate issued to a real domain name, but that did not make a difference. (Even though I changed the certificate and the url, Outlook still showed a certificate warning, and I have no idea why!)

But I doubt that the certificate problems are related to my client issues. During my web research, I found a bug that has been existent on exchange 2016 servers, where the authentication on the mapi virtual directory has not been enabled, which caused those client connections to fail. I checked that (I installed exchange 2016 CU21), microsoft obviously fixed that bug - at my installation, authentication already has been enabled.

I am really lost now. Any hint on what could be wrong is appreciated!

Updated Info

Thank you for your reply: Concerning Outlook Version, I double checked it, it should be supported.

Microsoft Outlook 2010 (14.0.7268.5000) SP2 MSO (14.0.7268.5000)

Concerning the certificate warning: It is the first warning (The security certificate was issued by a company you have not chosen to trust.). Thank you for the hint about install certificate, I didn't know about this possibility.

What is really weird, I clicked on install, chose to install it for the whole computer, and closed outlook. After I reopened Outlook, the issue as above showed, and after a minute, the same certificate warning showed again, even though I installed and clicked on trust previously. I repeated the step, this time for the local user, and after a second restart, everything started working!

Why did I have to install the certificate twice ? Outlook connects only to the default website (ex2016.domain.local:443) and not to the exchange backend (ex2016.domain.local:444) correct ?

Here is the result of the powershell script (I removed all references to the old exchange server)

Transcript started, output file is C:\log.txt
 C:\Windows\system32>
 
 
PS>Get-OabVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL

Identity                      : EX2016\OAB (Default Web Site)
Server                        : EX2016
BasicAuthentication           : False
WindowsAuthentication         : True
OAuthAuthentication           : True
InternalAuthenticationMethods : {WindowsIntegrated, OAuth}
ExternalAuthenticationMethods : {WindowsIntegrated, OAuth}
InternalUrl                   : https://ex2016.domain.local/OAB
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-WebServicesVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL 

Identity                      : EX2016\EWS (Default Web Site)
Server                        : EX2016
CertificateAuthentication     :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
LiveIdNegotiateAuthentication :
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : True
OAuthAuthentication           : True
AdfsAuthentication            : False
InternalUrl                   : https://ex2016.domain.local/EWS/Exchange.asmx
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-OutlookAnywhere | fl Identity, server, *Auth*, InternalHostName, ExternalHostName


Identity                           : EX2016\Rpc (Default Web Site)
Server                             : EX2016
ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}
InternalHostname                   : ex2016.domain.local
ExternalHostname                   :



 C:\Windows\system32>
PS>Get-OwaVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL 

Identity                      : EX2016\owa (Default Web Site)
Server                        : EX2016
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : True
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
InternalUrl                   : https://ex2016.domain.local/owa
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-ClientAccessServer | fl Identity, Name, AutodiscoverServiceInternalUri

Identity                       : EX2016
Name                           : EX2016
AutoDiscoverServiceInternalUri : https://ex2016.domain.local/Autodiscover/Autodiscover.xml


 C:\Windows\system32>
PS>Get-EcpVirtualDirectory| fl Identity, server, *Auth*, InternalURL, ExternalURL

Identity                      : EX2016\ecp (Default Web Site)
Server                        : EX2016
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : True
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
InternalUrl                   : https://ex2016.domain.local/ecp
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-ActiveSyncVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL


Identity                            : EX2016\Microsoft-Server-ActiveSync (Default Web Site)
Server                              : EX2016
MobileClientCertificateAuthorityURL :
BasicAuthEnabled                    : True
WindowsAuthEnabled                  : False
ClientCertAuth                      : Ignore
InternalAuthenticationMethods       : {}
ExternalAuthenticationMethods       : {}
InternalUrl                         : https://ex2016.domain.local/Microsoft-Server-ActiveSync
ExternalUrl                         :



 C:\Windows\system32>
PS>Get-MapiVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL


Identity                      : EX2016\mapi (Default Web Site)
Server                        : EX2016
IISAuthenticationMethods      : {Ntlm, OAuth, Kerberos, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Kerberos, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Kerberos, Negotiate}
InternalUrl                   : https://ex2016.domain.local/mapi
ExternalUrl                   : https://ex2016.domain.local/mapi



 C:\Windows\system32>
PS>Get-PowerShellVirtualDirectory | fl Identity, server, *Auth*, InternalURL, ExternalURL


Identity                      : EX2016\PowerShell (Default Web Site)
Server                        : EX2016
CertificateAuthentication     : True
InternalAuthenticationMethods : {}
ExternalAuthenticationMethods : {}
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication      : False
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : False
OAuthAuthentication           : False
AdfsAuthentication            : False
InternalUrl                   : http://ex2016.domain.local/powershell
ExternalUrl                   :



 C:\Windows\system32>
PS>Get-ExchangeCertificate | fl Identity, FriendlyName, Subject, CertificateDomains, Services, Issuer, *not*, Status


Identity           : EX2016.domain.local\xxxx_Cert_1_xxxx
FriendlyName       : Microsoft Exchange Server Auth Certificate
Subject            : CN=Microsoft Exchange Server Auth Certificate
CertificateDomains : {}
Services           : SMTP
Issuer             : CN=Microsoft Exchange Server Auth Certificate
NotAfter           : 10.09.2026 15:12:39
NotBefore          : 06.10.2021 15:12:39
Status             : Valid

Identity           : EX2016.domain.local\xxxx_Cert_2_xxxx
FriendlyName       : Microsoft Exchange
Subject            : CN=EX2016
CertificateDomains : {EX2016, EX2016.domain.local}
Services           : IIS, SMTP
Issuer             : CN=EX2016
NotAfter           : 06.10.2026 15:11:29
NotBefore          : 06.10.2021 15:11:29
Status             : Valid

Identity           : EX2016.domain.local\xxxx_Cert_3_xxxx
FriendlyName       : WMSVC-SHA2
Subject            : CN=WMSvc-SHA2-EX2016
CertificateDomains : {WMSvc-SHA2-EX2016}
Services           : None
Issuer             : CN=WMSvc-SHA2-EX2016
NotAfter           : 04.10.2031 12:32:50
NotBefore          : 06.10.2021 12:32:50
Status             : Valid

Identity           : EX2016.domain.local\xxxx_Cert_4_xxxx
FriendlyName       : real.domain.org (rapidssl rsa ca 2018)
Subject            : CN=real.domain.org
CertificateDomains : {real.domain.org}
Services           : IMAP, POP, SMTP
Issuer             : CN=RapidSSL RSA CA 2018, OU=www.digicert.com, O=DigiCert Inc, C=US
NotAfter           : 05.11.2021 13:00:00
NotBefore          : 07.10.2019 02:00:00
Status             : RevocationCheckFailure



 C:\Windows\system32>
PS>Get-OrganizationConfig | fl MapiHttpEnabled


MapiHttpEnabled : True


 C:\Windows\system32>
PS>Get-CasMailbox -Identity Dummy.User | fl MapiHttpEnabled


MapiHttpEnabled :


 C:\Windows\system32>
PS>Stop-Transcript

I am currently working with a small Ubuntu-Server running on a raspberry pi to provide some services in my network. To extend the lifetime of my SD-card, I am trying to use an overlay-fs (see here for example). I found a nice ready-to-use package "overlayroot". This works as a charm, but since I wanted to use a tmpfs as upper layer, I would need to backup the upper layer on a regular basis (To an external storage, like a NAS or a different PC).

Since the upper layer filesystem is just like an incremental backup, I really like the idea of saving once the lower layer somewhere, and after that keeping only daily backups of the upper layer.

I tested around a bit - when I delete a file present in the lower layer, a special file is being created in the upper layer, marking the deletion of that file. A tar-archive of the upper layer correctly packs that file and unpacks it again - problem here is, this is not working "on the fly", meaning unpacking the archive in the upper layer while the overlayfs is already mounted. When I'm trying to do this, interesting errors occur, which shows that the kernel didn't notice all of the changes made to the upper layer filesystem. (When you try the same thing before mounting the overlay, it works like a charm!)

My question is, does anybody have an idea how to "restore" the filesystem from a tar-archive on the fly (since unmounting the root filesystem is not possible...) Of course, I could hook the restoration somewhere inside the initramfs-tools (where the rootfs gets mounted) - but I really don't like messing around with that... is there any other option?

I am currently puzzled by the dnsmasq configuration, and I hope someone here can help me... I've setup successfully the DHCP-Server with dnsmasq, and I've tried to include some static Host configurations based on the MAC-Addresses of the clients. Here is my dnsmasq.conf:

# port to listen for DNS queries. If set to 0, disables DNS functionality.
port=0
domain=fritz.box
dhcp-range=192.168.13.50,192.168.13.150,255.255.255.0,4h
dhcp-range=192.168.13.0,static,255.255.255.0,12h
dhcp-boot=pxelinux.0,pxeserver,192.168.13.10
# Gateway
dhcp-option=3,192.168.13.1
# DNS
dhcp-option=6,192.168.13.1
# Network Broadcast Address
dhcp-option=28,192.168.13.255
# Network Time Servers
dhcp-option=42,192.168.13.1

# linux-gurke
dhcp-host=00:1e:4f:d7:24:5e,192.186.13.6


pxe-prompt="Press F8 for menu.", 60
pxe-service=x86PC, "PXE boot from raspi", pxelinux
enable-tftp
tftp-root=/var/lib/tftpboot
dhcp-authoritative

But for some reason, even though I have an matching dhcp-host line - the host is not getting the static ip:

Oct 30 19:53:51 raspi dnsmasq-dhcp[9759]: DHCPDISCOVER(br0) 00:1e:4f:d7:24:5e
Oct 30 19:53:51 raspi dnsmasq-dhcp[9759]: DHCPOFFER(br0) 192.168.13.92 00:1e:4f:d7:24:5e
Oct 30 19:53:51 raspi dnsmasq-dhcp[9759]: DHCPREQUEST(br0) 192.168.13.92 00:1e:4f:d7:24:5e
Oct 30 19:53:51 raspi dnsmasq-dhcp[9759]: DHCPACK(br0) 192.168.13.92 00:1e:4f:d7:24:5e linux-gurke

What am I missing / doing wrong ? Any ideas?

I have a domain with a small v-server configured for mail reception / delivery with Postfix and Dovecot. Since I'm a little bit paranoid, I used gocryptfs to encrypt local mail storage on disk. This leads to a problem: When the server-hoster decides to restart the server (which happens mostly during the night), mounting the encrypted file system requires entering a password. Due to security reasons, I do not want to store that password on the server, which means, I have to manually logon to the server, and enter the password.

This leads to an ugly side-effect: Due to the missing mount, dovecot cannot start until the password is entered. If someone tries to send me an email in this period of time, my postfix puts the incoming mail in queue, tries LMTP transport to dovecot a couple of times, and after the configured maximal_queue_lifetime (which is quite short in my case, 1h only), a bounce message is being returned to sender.

What I want postfix to do instead, is to hold on to the mail, until it is able to deliver it to dovecot. A couple of ideas:

• increase queue lifetime (is this possible only for "incoming" emails, not for outgoing?)
• From reading & searching, I learned that it is possible to put a mail on hold (how ? is it possible to define a condition "if not exist unix-lmtp socket, put mail on hold" )
• Any other suggestions ?

Thanks for your help!