Hagen von Eitzen's questions

I have a Windows server and so far shared a folder D:\AAA as "ShareRW" with full share permissions ("Everyone - Full") and some stricter NTFS permissions as required on and below that folder; for example, UserX has full access to D:\AAA\BBB, read access to D:\AAA\CCC and cannot even see D:\AAA\DDD (because it has inheritance disabled and explicit rights only to other users). I checked on the server that the effective rights of UserX are indeed as desired.

Now I wanted to add the option to "mount -r" the same content and therefore created a second share with a different name "ShareRO" on the same folder and with only "Everyone - Read" permissions (and of course with the same old NTFS permisssions).

Now my UserX does both NET USE W: \\server\ShareRW and NET USE R: \\server\ShareRO. I expected R: to look the same as W:, except that writing/changing is not allowed. But reality begged to differ:

• The user can change stuff in W:\BBB, they can read stuff in W:\CCC, and they do not even see that W:\DDD exists
• The user can read stuff in R:\BBB, they can read stuff in R:\CCC, but they see that R:\DDD exists and some metadata (size, creation date) though they cannot open it.

What am I doing wrong here?

Perhaps this is a somewhat broad question, but I am currently relying on shots in the dark ...

We sometimes provide access to some web URLs (running Apache 2.4) protected by basic password protection. I have never seen it myself, but every now and then I hear from external users that they are immediately seeing a 401 Unauthorized error. While it is true that the server reply is by design a 401 error code, it is also accompanied by a www-authenticate header, and this should trigger a login dialog at the user's end (where they should enter the credentials we gave them). In the cases in question, it is reported that no login dialog appeared. Unfortunately, I never have direct contact with the affected external users that would allow me a deeper analysis.

• Does there exist a somewhat common browser that does not understand the www-authenticate machanism? CanIUse surprisingly suggests that Sfari and Opera are problematic - however I just made a successfull test with one of them.
• Do there exist other common obstacles, e.g., firewall policies that rigorously strip the needed http headers?
• Any other ideas what could be going wrong in these cases, or what I could test?

EDIT: Regarding things that were suggested for consideration:

• The URLs in question are https: (may I say - of course?)
• The problems occur with first-time users, i.e., they never get "in" in the first place. (Nevertheless, my understanding would be that a cached wrong password is supposed to trigger the dialog for the user to try again). This also seems to rule out password manager problems
• I doubt that the affected users have settings in place that make them automatically try their windows credentials or other automatic logins with (to them) foreign internet hosts.

Background: Many of my users use smartphones, mostly iPhones to access their in-house MS-Exchange mail accounts via ActiveSync. After the recent security problems with iOS older than 13.5, we had recommended everybody to disable the native iPhone mail app. As a replacement we suggested the Microsoft Outlook App.

Once iOS 13.5 came out, we also suggested to switch back to the native App and uninstall the MS App. In parallel, we had been observing a significant and growing load on our Exchange and fast growth of transaction logs between daily backups (which clean the logs). It did not get better by itself within a few days and the danger became imminent that our disks cannot hold the log volume of two days so that we'd be doomed if ever a daily backup should fail. Consequently, we took measures for a more detailed analysis. The culprit were tons of ActiveSync hits, sometimes several thousand per user per day. But there was a correlation: All users with enormous hit counts came in with Outlook-iOS-Android/1.0 as user agent. This was not that surprising during our first analysis when "everybody" used that App. However, after several users had switched back, the situation remained the same. Those using the native iPhone App (again) caused signifcantly (i.e., by an order of magnitude) less load and log volume.

Hence we mailed affected users to more urgently switch back to the native App, and already a few of them doing so gave immediate relief - enough for us to no longer worry about the system stability. It was clear that not everybody would switch immediately and also that a handful would certainly completely ignore our demands.

But we were surprised when one user reported to have switched back and yet he still occurred as Outlook-App user (as well as with a different device id with native app). We asked the user specifically whether he had another (private) device active. He denied; the only way he'd ever access mail from his private phone would be ad hoc via browser and Outlook Web Access, and that very rarely as he usually has his office phone with him. With this information, the load of Outlook-App accesses under his account count as suspicious.

I investigated further and found out that these accesses also came from suspicious IP addresses. While other ActiveSync accesses originate from regional (here: German) phone provider ip ranges, those Outlook-App accesses originate from 52.97.x.x, which according to whois belongs to MicroSoft. While this is at least not some obvious Chinese/Russian hacker ip range, this still does not look comforting to me.

Q1: Is it normal that Outlook-iOS-Android/1.0 takes a detour across Microsoft's net range? I'd be happier if mails could only be read by those allowed to do so and not (at least possibly) also by some proxy possibly under US control. I may then even have to completely disallow the use of that App under GDPR.

Q2: Is it normal that Outlook-iOS-Android/1.0 causes such an enormous load? As far as I can tell, the client does not even have any configuration option that would allow the user to request a sync every 30 second, say.

Q3: Is it normal that Outlook-iOS-Android/1.0 (or said proxy) still causes load after it is no longer installed on any device of the user?

Since uninstalling for some users did reduce load, Q3 is what surprises me most (whereas Q1 is what worries me most and Q2 is what confuses me most).

Q4: What should I do? I am close to blocking the MS network range for incoming requests on port 443 at the firewall ...

We are running four ESXi 6.5.0 VMware hosts, managed vie vSphere web client.

Recently, I added a new VMFS 6 volume in our storage, originally created with 2TB capacity, but quickly extended to 3TB before actually taking it to production. Ever since, I do not get consistent volume cacpacity readings. For example: A guest system had a disk of 1700GB originally on a different volume; I migrated that to the new volume, and after that try to enlarge it. So in change settings, the disk showed as 1700GB and maximum size 2.77TB - but when I attempted to set it to 2000GB, I got an alarm "insufficient disk capacity", and - lo and behold - the maximum size had gone down to 1.86TB! With this, I managed to increase my 1700 to 1900GB only ...

When checking the volume info under "configure" - "general" - "capacity", it sometimes shows 1.86TB as capacity (and allocated), but sometimes without anything special happening in-between it shows 2.77TB (with 1.86TB allocated). At times when the lower capacity is shown, clicking "update capacity" changes nothing.

Under "device backing", it shows 2.77TB (as far as I can tell without fluctuation?).

Under "monitor" - "performance" - "overview", I sometimes see 2.77 and sometime 1.86TB as well.

And so on ...

Each of the four hosts shows the volume correctly as LUN 10 = 2.77TB.

Strangely, the event log for the volume shows several entries "Capacity of ... enlarged from 2047894093824 bytes to 3047816167424 bytes". More specifically, I have the "volume created" event at 2019-07-05 11:44:16 and those "capacity extended" events at 2019-07-05 13:33:44, 2019-07-05 13:37:04, 2019-07-05 15:23:28, 2019-07-05 15:53:40, 2019-07-05 16:23:41, 2019-07-05 17:19:30, 2019-07-10 07:58:05, 2019-07-10 09:58:01. That's eight times up to now, way more than e.g. once per host, and mostly (but not completely) correlated with times when I have vsphere open, all in all not really explicable to me.

Questions:

• What can be the cause of these observed fluctuations?
• How can it be mended?
• Once mended, how can I then be sure that it has been mended for good (I do not want to extend a disk an then be informed at a random moment that pat of the disk does not "exist")?

(I first posted this here, but it was suggested to be more on topic here)

I want to run the "same" WLAN in two independent sites (in different cities) in such a way that a user once connected to the WLAN in City A can easily connect in City B as well. As it turned out, just using the same SSID FOOBAR won't work. For example, in Windows boxes, you have to remove the known FOOBAR and then search again for available WLANs - aparently, the FOOBAR "here" is somehow different from the FOOBAR "there". In a way, it is understandable that just publishing the same SSID name should not be sufficient - after all anybody could just setup popular SSIDs, have walk-by clients attempt to automatically login with their credentials, and collect the data.

While both sites have their own WiFi management (a Sophos UTM), in the background all essentialities should be the same: Authentication is via a common RADIUS server (connected to both sites via tunnel) and therupon by MSCHAP via a common Windows AD server. So my question is: What else that must be kept in sync between my two cities in order to make the WLANs the "same" in a manner sufficient to allow automated connect to the second site the same way one re-connects to the first site? Is it some kind of private key or shared secret perhaps? In another forum, they suggested using the same DNS server IPs in both sites, but this appeared not to work for me. (However, one thing I cannot make the same in both sites is the IP range)

In case the answer depends on the type of clients, I am primarily interested in Windows 10 systems, but also iPhone/Android smartphones.

Below, all error messages etc. are given here as translated by myself from German. The English original may differ

We have the following setup

• Server A: Windows 2016 with RDP Session Broker and RDP Licensing for two RDP farms
• Server B1, B2, ...: Windows 2016, RDP Session Host, members of first RDP farm
• Server C1, C2, ...: Windows 2016, RDP Session Host, members of second RDP farm

Until recently, I could manage the farms (e.g., disable logins for single farm members, manage and shadow user sessions, ...) from Server A and its Server Manager. However, today the following happens and I cannot get rid of it:

On Server A, in Server Manager, I have A, B1, B2, ..., C1, C2, ... in the server pool (i.e., listed under "All Servers" as well as under "Remote desktop Services" - "Servers").

• When selecting Remote Desktop Services, the menu shows "Overview" and "Servers", whereas the expected behaviour is that there should be a third item "Collections" with the two farms as sub-items

• In "Overview", it says

  There is no remote desktop server deployment in the server pool. In order to create a deployment, run the wizard to install roles and features and select "remote desktop services".

  However, all that I think is needed, is already installed: the role remote Desktop Service (with sub-roles licensing, session host, session broker, web access)

Just for fun, I went to another server (Server B1), started Server Manager, added the same servers to the server pool, and - voilà! - everything works there ("Overview" shows the graphical overview etc., "Collections" has all farms below it, I can configure and manage the farms and their member servers as well as individual sessions)

On Server A, I tried to remove some of the session hosts from the server pool. Then "Overview" correctly noticed that these were missing and urged me to add them to the server pool, which I did. But the original problem did not go away. Of course I also rebooted server A, but that did not help, either. EventLog shows nothing of interest.

Q: What got broken on Server A?

Update: Doing more research, also including hints from the comments, I tried the following: In Add Roles and Features, I pick "Installation of RDP" and am told "There already is a Remote Desktop Deployment in the server pool ...", so the exact opposite of what the messages say elsewhere! Any attempts to continue, however, (no matter if standard or quickstart or multipoint) lead to an error "Deployment information could not be retrieved from RD connection broker 'Server A'"

I manage several Windows 2012 based DHCP servers and on one of these I came across a peculiarity that I cannot explain and do not know where to correct:

In DHCP manager*, expand [server name], then IPv4, policies (or [network], then policies). Create a new or edit an existing policy and in the conditions tab, add or edit a condition.

The expected behaviour is that you are presented with a dialog where you can pick

• a criterion (vendor class, user class, MAC address, etc.)
• an operator (equals, not equals)
• a value field**
• a prepend wildcard checkbox**
• an append wildcard checkbox**

At least this is the case with the majority of my servers. On one single server, however, the "prepend wildcard" checkbox is always disabled:

Q: How come? What does this signify? Is there a problem or misconfiguration? Of course, to my knowledge all servers are (or should be) mostly identical as far as updates and configurations are concerned ...

* All options, dialog labels etc. are translated back from the German version, hence I'm sorry if there is no perfect match with the English version

** The form has different fields when picking relay agent info as critrion, but that is irrelevant for this question

Every now and then our Exchange 2013 server (running on Windows 2008R2) will reboot during office hours, typically in the early afternoon (say, somewhere between 15:00 and 16:00) - apparently because the server thinks it wouldn't hurt anybody because nobody is really logged in. The reboots are always related to the server installing new upgrades automatically and users are annoyed because their Outlook makes problems (if they are lucky, it simply reconnects after a few minutes, but if they were in the middle of composing a longer mail the only way to save their work is by copy-pasting all to an empty Word doc, say, and restart Outlook).

The update settings are as follows:

• install automatically (recommended)
• install daily at 06:00

So even if an update process should somehow take a whole hour, the reboot that might be necessary should happen at 07:00 in the morning and not nine to ten hours later, shouldn't it?

I would like to keep the update process as admin-friendly as possible, i.e., without the need to manually install updates off-hours or to manually schedule a reboot.

Q1: Why can it happen that the automatic reboot (always?) happens so many hours after the scheduled update installation time?

Q2: Is there any way to gobally prevent automatic reboots during office hours, i.e., to automatically delay an auto-reboot scheduled for between 08:00 and 18:00 to happen at 23:00 instead?

I do see that I can't enable the Meltdown/Spectre mitigations in Windows Server 2008 R2 is a similar question, but I suppose that the environment differences may justify different remedies.

After installing the Meltdown/Spectre related Windows updates and registry keys, and verifying that the relevant Vmware patch is installed (more precisely, ESXi550-201709101-SG is listed as "considered obsolete by the host", as is ESXi550-201709102-SG, but ESXi550-201709103-SG is installed).

The Microsoft testing tool gives me only

Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]

Suggested actions

 * Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation.


BTIHardwarePresent             : False
BTIWindowsSupportPresent       : True
BTIWindowsSupportEnabled       : False
BTIDisabledBySystemPolicy      : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired              : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled           : False

I dare to interprete these (in particular regarding CVE-2017-5715) as

• CPU is vulnerable
• Windows updates have been installed
• Registry settings are missing
• GPO is not a problem
• Appropriate Microcode/Firmware is missing

This confuses me. For one, the registry settings should be ok according to the following export excerpt:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"FeatureSettingsOverride"=dword:00000000
"FeatureSettingsOverrideMask"=dword:00000003
"FeatureSettings"=dword:00000003

Additionally, I don't understand why the required microcode is missing (and hence BIOS/firmware update is suggested) given that the underlying VmWare host has ESXi550-201709103-SG installed (note though that ESXi550-201709101-SG comes with a footnote that it mitigates against CVE-2017-5715 but not against CVE-2017-5753)

What should I do?

Update

Meanwhile, I did also install BIOS/firmware (specifically, for the underlying ProLiant BL460c Gen 9 blade, I installed BIOS version 2.54 12-07-2017 (Fixes: "Updated the Intel processor microcode to the latest version."). The blade/host as well as the guest have been rebooted afterwards, but I still get the same test results (FTFFTTTTF and I am still suggested to "Install BIOS/firmware update provided by your device OEM ..."). I even had the guest boot into its BIOS and flipped through the settings to see if something needed to be enabled (apparently this is not the case).

Update 2

Out of curiosity, I tried the Linux testing tool as well. That tells me "Hardware (CPU microcode) support for mitigation: YES" even on a blade that had only ESXi550-201709103-SG installed, but not yet ProLiant BIOS 2.54.

I used this sequence of netdom commands to rename one of our AD controllers from "A" to "B". The rationale was that the historical name "A" would be much better suited for a new server that we want to install. This renaming "A" to "B" went smoothly and in particular, the AD functionality is up and running.

However, we managed to install the new server only under a new name "C". It can also readily be renamed to "D" or "E" or ... , but not to "A". I thought it might be the old DNS name still being around. Instead of waiting weeks until it would age out automatically, I deleted it from DNS, but ths did not help.

What I get when attempting to rename "C" to "A" is an "internal error", without any notable messages in the event log. What could cause this?

One of my users found a message in his Sent Items folder and claims he has not written it. The (external) recipient address exists and is knwon to us (though said user doesn't know it and had no contact so far), the subject is appropriate and very specific to that recipient address (and to no other recipient), the mail body contains a single word "Einverstanden" (German for "agreed"), which looks like a rply to something, but isn't. This looks a bit strange (though not strange enough to suspect malware)

Is there any way to find out in greater detail how the mail was actually produced? (Which Client on which computer / OWA / smart phone with ActiveSync / other user with "Send As" privileges / ...) While "internet headrs" are very informative for inbound mail, the corresponding field is (logically) empty for this outbound mail ...,

EDIT: Thanks to hints in the comments I found more logs than I knew before. Here's what I found:

• In RPC ClientAccess Logging I found my user was active from 13:45:07.137 until 13:45:51.270 (this was really him and his PC, according to the IP logged with the first of these lines)
• In Connectivity Log, I found an entry MapiSubmission at 13:45:51.504, followed by entries related to SMTP forwarding starting at 13:45:51.878

I assume that the sequence of events logged herein, including the time deltas of about 0.3 seconds between steps, is in fact "normal" and contarry to what the user claims, this looks extremely as if he had sent the mail by Outlook?

We are distributing wireless profiles in our Windows domain (AD servers are 2012, domain level is 2008, various client Windows versions - mostly Win7 and Win10). However, it seems we just cannot achieve the goal we want to achieve regarding saved credentials. Under "Computer configuration" - "Policies" - "Windows settings" - "Security settings" - "Wireless network policies (IEEE 802.11)", we created a "Vista and later" policy with one profile, and this has in its security pane the (seemingly only applicable) setting "Cache user information for subsequent connections to this network".

• If we uncheck this option, users are asked for their username and password each time they connect to our WLAN. The problem with this is that we'd prefer if the credentials do not have to be entered so often.
• If we check this option, users are asked only once and never again. The problem with this is that the user is not even asked for credentials if the password has been changed in the meantime and so the saved password has become invalid. In this situation, there seems to be no way for the user to re-obtain WLAN connectivity.

Questions:

1. Is there any way for the users to update the login credentials with the second scenario above?
2. Preferably, is there any way to configure the profile such that connection failure due to login failure makes the username/password dialog pop up, thus allowing the user to store the changed credentials?

In Windows Active Directory (in connection with Exchange 2010), I am unsure about the semantic difference between mail: and proxyAddresses: attributes. As far as I can tell, mail: is one-valued whereas proxyAddresses: is multivalued and (apart from the possibility to include non-SMTP addresses) allows one value starting with SMTP as main address and several values starting with smtp as secondary addresses.

I think I recall that in former versions of Windows and/or Exchange the main proxyAddresses was always kept in sync with the mail attribute. But I now noticed that these are no longer automatically kept in sync (depending on how one edits the data). So it may happen that I have a user with

mail: [email protected]
proxyAddresses: SMTP:[email protected]
proxyAddresses: smtp:[email protected]

So any mail that user sends will use <[email protected]> as sender address; incoming mail addressed to either <[email protected]> or <[email protected]> will end up at that users mailbox; but where does <[email protected]> come into play?

So the questions I have are

• Is there any specific purpose where the mail attribute is used?
• Does it ever make sense to have different mail: and proxyAddresses:SMTP entries as above?
• If the answer to the preceding question is "no": What am I doing wrong that causes mail: and proxyAddresses:SMTP to be no longer kept in sync?

I have several Windows servers with DNS and AD roles, some are Win2003, some are Win2012. There is an AD-integrated zone example.com that contains an ip 192.0.2.1 for example.com and an ip 203.0.113.1 for bar.example.com.

• A DNS query for bar.example.com returns the ip 203.0.113.1 as expected, no matter which server is asked. (Especially, we can be confident that replication has completed)
• A DNS query for example.com asking any of the Win2003 servers returns the ip 192.0.2.1 as expected
• A DNS query for example.com asking any of the Win2012 servers returns "Host not found"
• A DNS query for SOA or NS records of zone example.com asking any of the Win2003 servers returns the correct information
• The same query asking any of the Win2012 servers returns "Host not found"

I also tried to turn the zone into a non-AD-integrated one that is only served form the old servers. I hoped that the Win2012 servers would then return the correct answer per forwarding. But this didn't work out either ...

Meanwhile I noticed that I have another zone that has practically the same structure - and there the problem does not occur! I went through all properties of both zones - the only a differences are between SOA serial numbers and the MinTTL settings.

What is going wrong here?

Edit: Forgot to mention: In DNS Manager on the problematic servers, all records show up - it is just that they are not returned to DNS queries.

A previously nicely functioning Remote Desktop Server Farm ahs stopped working two days ago. The setup is as follows:

• DNS resolves "myfarm.mydomain.local" to the IPs of all the farm member servers
• All farm member servers are configured as farm members of farm "myfarm" on Broker MYBROKER
• All farm members are members of the local session broker group on MYBROKER
• Clients are configured to connect to "myfarm"

(All servers involved are virtual Windows2008R2 boxes). Suddenly people started getting the following error (translated from German) and failed to connect.

Unable to connect to terminal server.

The terminal server farm "myfarm" that you are trying to connect to is redirecting you to server "farmmemberX.mydomain.local". Remote desktop cannot verify that this server belongs to the same server farm. This can occur if there is a server on your network with the same name as the server farm. ?It cannot be verified if both remote computers belong to the same remote desktop server farm. You must use the farm name, not the computer name, if you want to mak a connection to a remote desktop server farm.

Contact a network administrator to obtain support if you use a RDP connection that was prepared by the administrator.

If you want to connect with a specific farm member, use "mstsc /admin"

Sometimes it seemed also that they were simply rejected as if having entered wrong credentials (which they have not, most have saved their credentials)

Question 1. Can you explain what is behind this, specifically regarding the "it could not be verified": How does this verification take place if it works? After all, the redirection would not even be attempteed if it were not initiated by broker ...

What we tried: Sometimes it helped to replace the name the client connects to with something else (i.e., we added a name "foo" to DNS that resolved to the same IPs and had users connect to "foo"), but this was far from consistent.

Later we noticed that always the same few servers appeared as "farmmemberX" in the above error message. We experimentally removed these from the farm (at the members themselves and in DNS) and were thus able to reduce the broken eight server farm to a functional two server farm. As this would not be sufficient tor out user load, I wanted to clone one of these; in order to do so I first shut it down and later restarted it - from which moment on it was as bad as the other six servers. Apparently restarting the RDP servers was the fatal thing to do ... According to the logs, this particular server had not been restarted for about two months. So virtually any change made in the last two months could be relevant. Among these are

• We added our first Win2012 AD server into our otherwise Win2003 AD structure
• I recall there were a few cases of IE10/SSL/TLS related security problems that would require manual intervention (regedit and stuff), but am still trying to remember what these might have been
• Tons of windows updates
• Things like invalidated certificates came to my mnd, but I found no such thing

Question 2. Could any of these things cause this problem?

Currently, we dropped the server farm completely, i.e., we only have "poor man's load balancing" via DNS round robin (and we especially miss the reconnect-to-previous-session feature of course)

Main Question. How can I get my farm into working condition again?

EDIT: I should have mentioned that a few clients were lucky and had not peoblems with the RDP farm: those who were still running Windows XP and its older RDP client ...

EDIT after comment: It seems that the main blamed updates KB3002657, KB3035017 were either not installed, or had been installed days before the problem started on the relevant servers (clients, RDP servers, broker, DCs), but I'll try with unsinstalling them anyway ...

UPDATE Some more info:

• I enhanced the event logging on the broker. According to that log, all is fine (no warning) and the session redirect completes normally. It is just that after soe timeout the target session is removed. I tried (failed) in quick connections and in that case, the broker even logged that it tried to reuse an existing session.
• If the target RDP server is set to "RDP-Sercurity" instead of "negotiate", the redirect works (except that the expectable annoying error messages occur to the client)
• I tried a completely new farm (i.e., a different broker with different hosts) and the problem can be reproduced in this system as well. This may suggests that the problem is client-side.

UPDATE with info as requested per comments

If I set security to "TLS 1.0" (instead of "negotiate") at the RDP hosts, the problem persists. If I set to "RDP" the farm works - but everybody has to enter their password twice. In the error situation, for some reason I now often simply get "No connection could be established with the given credentials" instead of the original error. This is accompanied with a login failure event 4625 with status 0xc000006d, substatus 0. Before you ask: All DCs have their clocks in good sync; no LanMan compatabilty settings have been configured in the registry.

The certificates on the RDP host client settings that worked were issued by the still trustworthy internal CA (trusted by all as per GPO) and valid until at least four months in the future. For testing I cheanged these to "automatic" certificates and back, without success.

The original German error message text reads

Von Remotedesktopverbindung kann keine Verbindung mit dem Remotecomputer hergestellt werden.

Vom Remotecomputer "FARMNAME", mit dem Sie eine Verbindung herstellen möchten, werden Sie zum Remotecomputer "FARMMEMBER.DOMAIN" umgeleitet. Es kann nicht überprüft werden, ob diebeiden Remotecomputer zur gleichen Remotedesktop-Sitzungshostserverfarm gehören. Sie müssen den Farmnamen, nicht den COmputernamen, verwenden, wenn Sie eine Verbindung mit einer Remotedesktop-Sitzungshostserverfarm herstellen möchten.

Wenden Sie sich an den Netzwerkadministrator, um Unterstützung zu erhalten, wenn Sie eine RDP-Verbindung verwenden, die vom Administrator bereitgestellt wurde.

Wenn Sie eine Verbindung mit einem bestimmten Fammitglied herstellen möchten, um es zu verwalten, geben Sie "mstsc.exe /admin" an der Eingabeaufforderung ein.

To find out if some recent cleint-side update is at fault, I started with a fresh Windows 7 box and tested after each bunch of updates. It seems the introduction of the first better-than-XP client already causes problems now - but the first such client versions give a different error message (not that it makes sense):

Die Verbindung kann nicht hergestellt werden, da es sich bei dem erreichten Remotecomputer nicht um den angegebenen Computer handelt. Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden. Verwenden Sie statt des Namens die IP-Adresse es Computers.

We have a bunch of Windows 2008R2 servers used as RDP servers that are (or at least should be) essentially identical in configuration (and are arranged in a RDP farm). When administrating from home, I use remmina on Ubuntu. For unknown reason, there is one server among these that I cannot connect to from home unless I use different client-side settings. So apparently there are server-side differences, but I'm unable to find them and would like to ask what I could be missing.

Specifically, I can connect to all servers (but one) with the following remmina settings (under advanced):

• Quality: low (fast)
• Sound: Off
• Security: Negotiate
• connect to console: checked

For the problematic host, I need to adjust the client-side setting to either TLS or RDP. I cannot use NLA or Negotiate.

Here are the server-side settings that I consider relevant (Properties of the connection, "general" tab) and are identical between "good" servers and the "bad" one:

• Security: Negotiate
• Encryption: Client compatible
• Accept connections only from computers with Network level Authentication: NOT(!) checked
• Certificate: (issued by our internal CA)

Who can explain the difference?

We have a LAN with Cisco switches, redundant cabling and spanning tree. If I understand it correctly, when I pull out a redundant cable (that is currently "used" by the spanning tree) it takes several seconds until the spanning tree converges in reaction. How can I prevent this packet loss (assuming of course I know beforehand that the cable will be pulled)? That is, how can I make the spanning tree adapt "proactively"?

I would have guessed that an interface shutdown plus waiting a couple of seconds should suffice, but did not dare to try that out yet. Actually, I am afraid an interface shutdown would cause the same interruption times during convergence because I suffered from such an interruption yesterday when makeing a supposedly harmless configuration change at some interfaces. (Edit: I just confimed this experimentally; as expected there was some 20 seconds of interruption after interface shutdown - note that I am looking for a "lossless" soluiton, not just "less loss")

A Windows 2008 R2 machine reboots automatically every now and then, typically on Fridays afternoons. The reboots are "announced" in the event log as follows:

Event ID: 1074
process:  svchost.exe,  
user:     NT-AUTHORITY/System, 
reason:   OS:restore(planned), 
code:     0x80020002

I guess this is precisely the event one can expect if a Windows update from our WSUS server requires a reboot. However, as far as I can see, such reboots should happen at most at about 3 a.m. This has happened repeatedly this year, namely

1. 2013-01-10 03:15:12 - Probably due to an update
2. 2013-01-20 03:04:37 - Probably due to an update
3. 2013-02-14 16:35:27 - What's that??
4. 2013-03-06 16:23:07 - What's that??
5. 2013-03-15 13:49:12 - What's that??
6. 2013-04-14 21:18:36 - What's that??
7. 2013-04-26 14:58:54 - What's that??
8. 2013-05-17 15:51:41 - What's that??

If I check updates after today's reboot, it says

Last time checked for updates: Today, 15:47
Updates installed: Yesterday, 20:57

So, while the last check is suspiciuously short before the reboot, the last actual update took place yesterday (Forefront virus definition update, no reboot required).

What can be the cause? What can be done to prevent?

Please feel free to ask for more details.

Update: The nearest event log entries around the shutdown with source WindowsUpdateClient were:

• immediately after the event#1074 above: Event#27 "Automatic Updates" has been stopped
• at 13:00 (almost 3 hours before shutdown): Event#19: Installation successful (Forefront definition update)
• at 15:55 (quite shortly after reboot): Several events #19: Installation successful (several OS updates, security updates and cumulative security updates)

It is plausible tha the updates in the last point were waiting for a reboot. In fact, I found an event #22 ("Reboot necessary, computer will reboot in 15 minutes) on 2013-05-16 03:14:28 mentioning precisely the updates mentioned in the post-reboot events. However, why didn't it reboot at 3:30 a.m. yesterday as the event mmessage suggests instead of 4 p.m today?

By popular demand, the relevant policy settings under Computer configuration\Administratove templates\Windows components\Windows update according to the GPO modeling wizard:

• Configure automatic updates: Enabled with "4 - Download and install by schedule", "daily", "at 03:00 a.m."
• Automatic updates immeditae installation: Enabled
• Enable client-dide targeting: Enabled with "MyGroup"
• Specify intranet Microsoft update location: Enabled with updates and stats = "http://my-wsus-server"
• No auto-restart for scheduled updates with logged on users: Enabled
• Allow signed updates from an intranet Microsoft update service: Enabled
• Automatic Updates detection frequency: 22 hours

I don't have a bad feeling with these settings. The only suspect is No auto-restart for scheduled updates with logged on users. However, for the observed behaviour, a user must have been logged on at yestreday 3 a.m. until today 4 p.m. (or possibly several overlapping sessions). Sifting through the ocean of Security Event Log, I did indeed find: Three events #4634 (logoff), two for Administrator RDP sessions (type 10), one for Administrator console session (type 2), all in the very same second as the event #1074 above! But what is cause and what is effect? Or how come three sessions got killed simultanuously?

I'm trying to modify registry entries within HKCU at logoff. The corresponding script works okay when invoked manually. I was afraid there might be issues with a loopback policy kicking in, but according to rsop.msc this is not the case, i.e. the script should be executed. However, the desired effect in the registry is not there upon next login.

Is there a general problem simply because the script runs "too late"? If so what can be done? What else could this be?

EDIT: I should have specified what my logoff.vbsscript looks like (minimalized):

const HKCU = &H80000001

Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
' ...
oReg.SetStringValue HKCU,"SOFTWARE\Foo","Bar", "Baz"

I am using a powershell script to make some exporting from various Exchange mailboxes. The main point consists of creating a profile for each affected mailbox and invoke outlook.exe /importPRF customprofile.prf and so on. The main logic and everything works fine, but one problem occurs: If usernames are prefixes of one another (say I have "Foo" and "Foobar") then the profile for the shorter ("Foo") interrupts the automated script and instead a dialog window pops up whether I want to have "Foo" or "Foobar". The name enters into the profile file customprofile.prf in form of MailboxName lines

[Service List]
ServiceEGS1=Exchange Global Section
Service1=Microsoft Exchange Server
...
[ServiceEGS1]
MailboxName=Foo
...
[Service1]
MailboxName=Foo
...

What can be done so that no Foo vs. Foobar question pops up? In other words: It seems that "Foo" is really interpreted as something like a regex "/Foo.*/". How to make "Foo" really stand for "/^Foo$/" (though of course no regexes can be entered there)

(In case it is important: the usernames are the SamAccountName taken from Active Directory)