roaima's questions

Summary

The default MTU value prevents data transfer for one system. Reducing it manually enables the data transfer once more, but this manual adjustment is unnecessary on an adjacent system.

Background

I have a Backups Server. I have two Raspberry Pi systems in remote locations: one in the UK and one in Albania. Alongside the Albanian Pi is a QNAP (a Linux-derived fileserver). I have an IPSec VPN from Albania to the Backups Server network, and another IPSec VPN from the UK to the Backups Server network. Everything is using IPv4. This diagram may help:

                                           |--Albania Pi
                    |<--IPSec-->|--Router--|--Albania QNAP
Central  |          |                      |--Other systems
Backups--|--Router--|
Server   |          |                      |
                    |<--IPSec-->|--Router--|--UK Pi
                                           |--Other systems

Both Pi systems and the Backups Server all have nftables without any rules, and with a default policy of ACCEPT.

The two RPi systems, the QNAP, and the Backups Server all have a default wired ethernet MTU of 1500, as would be expected.

The router's WAN-side MTU for Albania is 1442, and for the UK it's 1500. According to the routers' Path MTU Discovery option these values are correct. For the firewall managing the network containing the Backups Server it's 1500, and this is also correct.

Problem

• If I transfer a block of data from the Pi in the UK to the backups server, it works fine
• If I transfer a block of data from the QNAP in Albania to the backups server, it works fine
• If I attempt to transfer a block of data from the Pi in Albania to the backups server, it fails
• If I reduce the Pi's MTU to 1374 the transfer succeeds

More information

Here's an example of the sort of thing that's working/failing

# On the Albanian Pi
dd bs=1M count=100 if=/dev/urandom >100M.dat

# On the Backups Server
ssh albanian_pi cat 100M.dat | pv >100M.dat

# MTU adjustments on Albanian Pi
ifconfig eth0 mtu 1500    # Default before I started fiddling
ifconfig eth0 mtu 1374    # Highest value that permits data flow

The transfer used to work, but that was before an upgrade from Stretch to Buster. I'm not seeing problems to most of the other Pi systems I have, and in particular not to the UK Pi I mentioned at the beginning that is now also running Buster.

No-one in the Albania office is complaining about network issues.

I've not knowingly got a "Do Not Fragment" bit set for packets between the Albanian Pi and the Backups Server. I've not knowingly got anything blocking PMTU Discovery.

To summarise:

• Albanian QNAP -> Backups Server: all good
• Albanian Pi -> Backups Server: fails without a reduction in the MTU
• UK Pi -> Backups Server: all good

I have a workaround, but I shouldn't have to reduce the MTU on individual systems.

Question

What is actually wrong, and how can I further diagnose and resolve the cause of the problem?

Suggestions gratefully received. Thanks

I have a Computer GPO in a Windows Active Directory based network (with on-premises Domain Controllers) that currently installs an application from \\MYDOMAIN\NETLOGON\...\application.msi at startup. This works well for all my machines that are network connected at boot, but I have a growing number of Windows users connecting via VPN, which means that the machine is not network connected until some point after user login.

In the absence of any obvious best practice alternative my proposed solution is to copy the application.msi to a hidden dedicated folder C:\localapps and to install from there.

The top-level folder creation works well. Copying the configuration file works well. Inherited permissions on the folder tree work well. What doesn't work is that the application.msi file cannot be copied.

Frustratingly, if I rename application.msi to application.msi.zzz the same GPO can - and does - copy the file to the local machine quite happily.

Further research, psexec -i -s explorer.exe gives me an Explorer window running as the GPO's SYSTEM account. Indeed, I can navigate to the appropriate place on \\MYDOMAIN\NETLOGIN and I can copy files from there unless they are named as executables or installers. All files in the folder have inherited permissions and I have confirmed they are the same. All files are "unblocked". All files have the same owner (MYDOMAIN\Administrators). I'm not trying to execute the MSI from the network share, just to copy it.

Empirical conclusion: the SYSTEM account used by the GPO cannot copy *.msi or *.exe files from the \\MYDOMAIN\NETLOGON\ share.

This doesn't seem to be a reasonable state of affairs, so how do I get my GPO to copy the application.msi as is, so that at the next opportunity it can be installed from the local disk?

I've got a Samba member of a Windows AD. I'm using a combination of sssd and winbind. Samba manages machine password changes, and it's configured also to update the passwords used by sssd. (The machine password update that is usually handled by sssd is disabled.)

The problem manifests on the Samba fileserver banas with this error:

net ads changetrustpw
Changing password for principal: [email protected]
Password change failed: No more connections can be made to this remote computer at this time because the computer has already accepted the maximum number of connections.

I can't find any useful matches to this error message via Google (everything I've seen seems to relate either to Windows XP or other Windows desktop systems trying to offer a network share to too many clients).

The trust is fine, inasmuch as I can browse to the shares offered by Samba, wbinfo -i returns sane and expected information for non-local AD accounts, and net ads testjoin returns the expected Join is OK.

I've enabled debugging on the changetrustpw command but nothing jumps out at me. The connection to the DC is made successfully, and negotiations follow, but with the final error once again.

AD is managed with DCs originally running Windows 2012 R2 but gradually being upgraded to Windows 2016.

Relevant snippet from smb.conf

[global]
server string Fileserver
server role = member server
server services = -dns
workgroup = CONTOSO
realm = CONTOSO.COM
security = ADS
encrypt passwords = yes
kerberos method = secrets and keytab
client ldap sasl wrapping = sign
passdb backend = tdbsam
idmap config CONTOSO : backend = sss
idmap config CONTOSO : range = 800000000-899999999
idmap config * : backend = tdb
idmap config * : range = 100000000-199999999

Relevant snippet from sssd.conf

[domain/contoso.com]
ad_domain = contoso.com
ad_hostname = banas.contoso.com
krb5_realm = CONTOSO.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
ad_domain = contoso.com
krb5_realm = CONTOSO.COM
use_fully_qualified_names = False
fallback_homedir = /home/DOMAIN=CONTOSO/%u
access_provider = permit
ldap_group_nesting_level = 5
ldap_use_tokengroups = false
ad_maximum_machine_account_password_age = 0

I have obfuscated, but consistently. For the purposes of this question, my domain is CONTOSO, contoso.com.

Nothing gets written to Samba or sssd log files during the changetrustpw attempt. The same configuration works as expected on other Samba members. Debian "Stretch" in all three cases if that's relevant.

I can add additional details on request - I simply don't know at this stage what else would be useful.

If anyone can either suggest a remedy to me (or failing that point me towards other resources that may help me diagnose and fix this), I'd be really grateful.

I've got one installation of SQL Server Enterprise and a couple of satellite installations of SQL Server Express. I can't justify additional installations of SQL Server itself for these satellites.

The documentation for SQL Server Express clearly states that it's limited to the lesser of one CPU or four cores.

What I can't seem to ascertain is whether this restriction for SQL Server Express really is per instance or per server. Some documentation uses the word "instance". Other documentation does not.

Instances don't seem to be much of an overhead (these days much of the SQL Server application is a shared installation, contrary to this older information). If this is an effective get-by to run several small-ish databases on the same server then that would be very convenient.

Can someone help clarify whether the limitation is per instance or per server, please?

In an effort to help reduce costs for the NFP organisation I work in, I'm hoping to find out which staff or volunteers have been assigned an Office2016 ProPlus subscription licence but not used it. (Managers tend to request it for all new starters regardless of job function, and such costs don't come out of their local budgets...)

Is it possible to identify users of licences that have been assigned but not used?

Sub-criteria that are not essential but would be nice are:

• Licensed users who haven't downloaded and installed the software from the Office365 Portal (there is a "mostly-accurate" report; several of my users are definitely using the software long-term but the report claims no activation)
• Licensed users who have not run any of the Office applications on their PC (in the last three months)

I'm not particularly looking for a full scripted solution (although I'd never say no to one). Rather, useful pointers to appropriate Powershell commands, or even menu options and reports within the Office365 Administrator Portal would be wonderful.

I have looked around but nothing popped out at me other than finding inactive users, seeing which users have been assigned what licences, counting unassigned subscriptions, and those I already keep at a minimal level (one or zero, usually).

I'm trying to rename a workstation that was joined to our domain last week. It's been rebooted at least once since then.

My domain is based on Windows 2012 R2 and the members in question are running Windows 10 Pro. In case it's useful information I have three DCs (and, yes, they are synchronised).

The rename works most of the time:

$aa = Get-Credential [email protected]
Rename-Computer -ComputerName mynewpc -NewName alpc001 -DomainCredential $aa
WARNING: The changes will take effect after you restart the computer mynewpc.

But I have a couple of machines which stubbornly refuse to allow the rename:

Rename-Computer -ComputerName otherhp -NewName alpc005 -DomainCredential $aa
Rename-Computer : Fail to rename computer 'otherhp' to 'alpc005' due to the following exception: Cannot create a file when that file already exists.
At line:1 char:1
+ Rename-Computer -ComputerName otherhp -NewName alpc005 -DomainCredent ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (otherhp:String) [Rename-Computer], InvalidOperationException
    + FullyQualifiedErrorId : FailToRenameComputer,Microsoft.PowerShell.Commands.RenameComputerCommand

Here's another attempt:

netdom renamecomputer otherhp /newname:alpc005 /ud:contoso\administrator /pd:*
Type the password associated with the domain user:

This operation will rename the computer otherhp
to alpc005.

Certain services, such as the Certificate Authority, rely on a fixed machine
name. If any services of this type are running on otherhp,
then a computer name change would have an adverse impact.

Do you want to proceed (Y or N)?
y
Cannot create a file when that file already exists.

The command failed to complete successfully.

There is no computer (or other account) with this new name, and there's no entry in the AD DNS for it either.

The additional error report from $error[0] | fl -f as requested in a comment is as follows:

writeErrorStream      : True
Exception             : System.InvalidOperationException: Fail to rename computer 'otherhp' to 'alpc005' due to the following exception: Cannot create a file when that file already exists.
TargetObject          : otherhp
CategoryInfo          : OperationStopped: (otherhp:String) [Rename-Computer], InvalidOperationException
FullyQualifiedErrorId : FailToRenameComputer,Microsoft.PowerShell.Commands.RenameComputerCommand
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}
PSMessageDetails      :

I don't have any IT support in the user's office, so we do as much as possible remotely. If all else fails I suppose I could grant enough privileges to the end user to unjoin their PC, rename it, and join it back again. But I really don't want to do that if there's a realistic alternative.

Suggestions gratefully received, thank you.

I've been asked for the output of NETDOM QUERY /Domain:{domain} WORKSTATION from each DC. The PC appears in the list for all three; here's a snippet from the results:

PS C:\Windows\system32> NETDOM QUERY /Domain:contoso.com /Server:DC1 WORKSTATION
List of workstations with accounts in the domain:

ALPC004      ( Workstation or Server )
...
OTHERHP
...

The PC in question (OTHERPC) does not have the ( Workstation or Server ) clause - but many of my PCs don't have this, either.

I have a Windows 2012 R2 server running as a VM (on top of KVM/Libvirt). It has an extra "internal" disk defined as F:

If I snapshot the Linux-based host's logical volume representing F: and mount it on the host I get many files tagged as being an unsupported reparse point.

What I want to do is to backup the filesystem from the host, which is why I've started from here.

Here is an example from the host's perspective

lvcreate --name shares-snap --size 10G --snapshot /dev/crypt_md3/shares
mount -o ro,offset=$((129*1024*1024)) /dev/crypt_md3/shares-snap /mnt/dsk
ls -l /mnt/dsk/mfc70.dll
lrwxrwxrwx 1 root root 26 Jan  5  2002 /mnt/dsk/mfc70.dll -> unsupported reparse point

Within the Windows guest, the file properties dialog shows its size to be 952KB but with the size on the disk as 0 bytes. This is classic for a reparse point. The advanced attributes are APL, with the L confirming that the file is indeed a reparse point.

Copying the file removes the P and L attributes from the copy.

Searching around lead me to How do you find the target of a symlink created with mklink and its accepted answer. I've downloaded both junction 1.06 and NTFSLinksView.

Running junction gets me nothing useful:

F:\> c:\local\bin\junction mfc70.dll

Junction v1.06 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

F:\mfc70.dll: UNKNOWN MICROSOFT REPARSE POINT

Running dir /L gets me nothing useful either:

F:\>dir /L mfc70.dll
 Volume in drive F is Folder shares
 Volume Serial Number is B600-69DE

 Directory of F:\

05/01/2002  04:48           974,848 mfc70.dll
               1 File(s)        974,848 bytes
               0 Dir(s)  233,785,053,184 bytes free

Running dir /A:L does include the file, so it's definitely a reparse point of some sort.

NTFSLinksView simply doesn't list the file.

After all this background information, the question is really rather simple:

1. How do I find out details of the reparse point?
2. What do I tell ntfs-3g on the host to remap the junction points so they resolve?

For a variety of reasons a significant number of our Windows PCs are not joined to our Windows 2012 R2 Active Directory domain. We are in the process of rectifying this, and are joining PCs on a per-office basis.

A number of our staff now have Windows 8.1 PCs and when they were purchased, they dutifully followed Microsoft's insistence to create a Microsoft Live account that is associated with the PC. Usernames are in the form of a UPN, which for the purposes of this question I shall treat as being Microsoft's demonstration domain, so [email protected]. These PCs have been configured by our remote staff in good faith; it's only now that I'm in a position to bring them on to our domain.

Unsurprisingly, the UPN that our staff choose coincides with the real one that we give them for our domain, so users log on to the PC using their email address (UPN) and then log on to central services also using the same account name. (This is not SSO because there is no trust relationship between Microsoft Live and our domain.)

I can join the PCs to the CONTOSO domain easily enough, and everywhere else the UPN works. I've also got a GPO ready to roll that will persuade these Windows PCs to default an unqualified username to sign on to our domain rather than to Microsoft Live. However, it seems that the way Windows 8.1 differentiates between a true local account, a Microsoft Live linked account and domain account is that the local account uses an unqualified name, the Live account uses a UPN, and the domain account is pushed backwards into using DOMAIN\Username style. We moved away from the CONTOSO\Username form a year or so ago as part of our parallel migration of email services to Office 365, and I'd prefer to continue having users sign in everywhere with a UPN.

I know I can migrate a user's local profile to a domain profile using something like the Forensit user profile migration wizard, so that deals with the data.

However, is there any sane way of migrating the UPN form of login on these PCs away from Microsoft Live and to our domain? I really don't want to have some people able to log in with a UPN but others having to remember to use the old DOMAIN\Username format.