Please help me understand this strange (to me) behavior

Goal

Allow delegated users to send-on-behalf-of other mailbox using OWA and iOS/Android apps.

Sent items should appear only once in the delegated mailbox (no sent item should be duplicated anywhere).

Configuration

Delegate has Full Access + Send On Behalf Of permissions to delegated mailbox

OWA Scenario 1

Messages sent on behalf of this mailbox will appear in the Sent Items folder of the: Sender mailbox

Delegates can send email from delegated mailbox - sent items appear only once in the delegated mailbox.

This is great from a desired behavior standpoint, but the Sender mailbox setting should cause the sent item to appear in the delegate's mailbox right?

OWA scenario 2,3

Messages sent on behalf of this mailbox will appear in the Sent Items folder of the: From mailbox

or

Messages sent on behalf of this mailbox will appear in the Sent Items folder of the: Sender and From mailbox

Delegates can send email from delegated mailbox - sent items appear twice in the delegated mailbox and not at all in the delegate's mailbox. Why??

I created a parity storage space on 3x external USB 4tb HDD attached to a Windows 10 1809 machine. I then moved those HDDs to a Server 2019 1809 machine and added 1x additional 4tb HDD.

I noticed there is an existing 32mb write-back cache in this HDD-only single-tier parity storage space.

Is there a way to determine where this is located or why it exists? I'm unsure if it existed on W10 machine, never checked, but imagine it must've. Only noticed it on Server 2019 machine because Server Manager displays it in the Storage Pools information.

Does Storage Spaces attempt to use host device SSDs/RAM for WBC even if they are not part of the pool? Why? Both W10 and Server 2019 machines have SSD host OS drives.

Similar to this question from half a decade ago..

Can the native MacOS IKEv2 VPN client be used in lieu of Cisco AnyConnect client?

example anyconnect profile:

<AnyConnectProfile> <ServerList> <HostEntry> <HostName>VPN01_HostName</HostName> <HostAddress>VPN01.cisco.com</HostAddress> <PrimaryProtocol>IPsec <StandardAuthenticationOnly>false</StandardAuthenticationOnly> </PrimaryProtocol> </HostEntry> </ServerList> </AnyConnectProfile>

and MacOS config that is not working (for me):

I have installed and enable RRAS and NAT on Server 2012 R2 with 8 interfaces. I assumed I would be able to select WHICH of the remaining 7 interfaces got NATed, but it appears ALL interfaces are NATed. This is undesirable. How can I prevent some of the interfaces from NATing through the public interface?

I'd prefer not to set static filters on every interface

It may be worth noting that I have only the 'Public' interface defined under the 'NAT settings. I have deleted all other 'Private' interfaces from the NAT settings, yet all other private interfaces are still being NATed out the Public interface. I have no address pools defined because I only want to NAT through the one Public IP address (assigned to the public interface)

I am setting up AD in an isolated network so that I can enjoy the benefits of Microsoft's Hyper-V replication/High-availabilty/clustering/etc.

This network does not have a default gateway and all IP addresses are statically assigned. Servers are 2012 R2.

A domain-joined machine identifies the network connection as 'Unidentified'

I do NOT want to manually override the firewall config to treat 'Unidentified' networks as 'Private'

I do NOT want to manually assign connection-specific DNS Suffixes to the interfaces.

I DO want domain-joined machines to identify the network as 'Domain'

I have read that "HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” is used to identify the network 'Location', but as I am not using DHCP and i do not want to manually configure connection-specific DNS suffixes, this key is blank.

As a test step, i tried to manually set the default gateway of the domain joined computer to the IP address of the PDC, (previously blank) and NLA immediately identified that I was on the domain network. This 'works', but is a bit of a hack.. as the PDC is NOT the Default Gateway, and would NOT be the default gateway if I were to add one later to de-isaloate the network.

As another test step, i manually set the default gateway of the domain-joined computer to an un-used IP address in the same subnet (the IP i would use if i had a router/default gateway). After a reboot the domain-joined computer still did not identify the network as 'domain'

How can i get the domain-joined machine to identify the network as 'Domain', without DHCP, without connection-specific DNS suffixes, and without default gateways?

Is there another way? DNS configuration?

I can't handle the incessant password prompting anymore..

Our Outlook installations prompt for a password after the comps wake from sleep and/or when changing between wired/wireless. Outlook DOES NOT prompt for a password when launching initially..AND, funny thing is, when it does prompt for credentials, users can simply dismiss the credential box, and then click on 'need password' in the bottom right corner of outlook, and connectivity is restored. How asinine is that? This behavior has me convinced that the credential prompt for RPC over HTTP DOES NOT HAVE TO BE DEFAULT BEHAVIOR Note, this works on all devices when they are connected to the LAN.. and when they DO NOT have any credentials saved in credential manager.

I have found many discussions claiming that if basic auth is used for RPC/HTTPS proxy, then password prompts are inevitable, but I can't believe MS would allow this behavior since they are now recommending RPC/HTTPS and deprecating NTLM, and based on the behavior described above, its clear that there is a method to pass the currently-logged-on credentials through basic auth.

Another reason i don't believe this is desired behavior is because MS released a KB to combat this issue (for 2007): https://support.microsoft.com/en-us/kb/956531

Here is another older KB https://support.microsoft.com/en-us/kb/820281, (unfortunately for 2003), that specifically says basic auth will always require a password, but this must be false (for 2007/13 combo at least) based on the behavior described above.

Here is an experts-exchange thread where I commented, but did not receive a response: http://www.experts-exchange.com/questions/27778514/Outlook-Disconnected-after-resume-from-sleep-mode.html

Can anyone help/comment on this behavior please? I am convinced that something is just misconfigured somewhere..

We have Exchange 2007 with Outlook 2013 clients. Corp IT decided NOT to use NTLM after the migration from 2003-07 because Microsoft advised that it is insecure and recommends NOT using it anymore.

Our setting are auto-discovered/configured so any changes I make to test get reverted. I have not tried to disable the auto-discover yet.

See screenshots below.

I have a third-party vendor providing a solution that uses a proprietary OPC server that runs as a user process (not a service). It launches when the Administrator account is logged in and an OPC client attempts to connect. As such, it runs AS Administrator.

My OPC client (on remote computer) runs under the SYSTEM account as a service. Unfortunately, with this configuration, my OPC client can't access the vendor's OPC server, because they are running under different credentials.

If I run my OPC client AS Administrator (on remote computer), I can browse the vendor's OPC server just fine, because both client and server are now running AS Administrator with identical credentials.

I'd prefer not to have my OPC client run AS Administrator - I'd like it to run AS SYSTEM, like most services do. I don't like having to custom configure MY systems to talk to third-party systems - I'd rather the third-party systems be responsible for talking to my systems as-is.

I've managed to get the vendor's OPC server running AS SYSTEM via psexec. Unfortunately, my OPC client (running AS SYSTEM) still can't see/connect to the OPC server.

DCOM is configured for 'Connect' and 'Identify', and the SYSTEM account is granted Local/Remote Launch/Activation permissions.

this document Kepware OPC config guide suggests that communication via OPC running AS SYSTEM should work.

Just for fun, I launched both the OPC Server and a portable Matrikon OPC client on the vendor's app server, via psexec, both running AS SYSTEM, both running in session 0, with interactive services enabled. Even in this situation, the OPC client, set to browse LOCALHOST, was unable to connect to the OPC server.

This is in a workgroup environment, though I don't think that is the problem.

I've done a bit of reading and as far as I'm aware, Session 0 isolation only 'isolates' services that have GUIs... nothing about network isolation..

What am I missing? Is it something simple?