Shaamaan's questions

We have a network share on a Windows Server 2022 which hosts a number of both "production" files as well as development files. We have two domains - a prod domain (ex. "prod.local") and a dev domain ("dev.local").

Some folders have been set up with "Everyone" access and, while a trust relationship was present between the prod and dev domains, dev users had read-only access to the shares, as expected.

However I've been asked to make the trust one way (dev trusts prod, prod doesn't trust dev) and now the "Everyone" permissions don't work any more.

I've tried to implement the changes suggested here but a) it seems those are solutions for Windows 10/11 and b) it still doesn't work (i.e. dev users still can't access the shares).

How should such a share be configured on a Windows Server to allow another domain access?

I've got a Docker swarm hosted on Windows Server 2022. I've created a credentialspec file since I need the service to use a gMSA. I've also defined a compose file to launch my service:

version: '3.8'

services:
  agent:
    image: privaterepo.local/devops-agent-win-generic:latest
    hostname: '${AZPOOL}_Generic-{{.Task.Slot}}'
    user: "NT AUTHORITY\\NETWORK SERVICE"
    security_opt: 
      - "credentialspec=file://domain_devopsagent.json"
    environment:
      AZP_URL: ${AZURL}
      AZP_POOL: ${AZPOOL}
      AZP_TOKEN: ${AZTOKEN}
      AZP_ONCE: ${AZONCE:-false}
      AZP_REMOVE: ${AZREMOVE:-true}
    deploy:
      replicas: 2
      placement:
        constraints: [node.platform.os == windows]

This starts the containers fine (no errors), and the containers seem to operate as NETWORK SERVICE, as expected, however they do not have access to the network shares as expected.

If I run the container manually then the container DOES have access to the network shares.

docker run --rm -it --user "NT AUTHORITY\NETWORK SERVICE" --security-opt "credentialspec=file://domain_devopsagent.json" privaterepo/devops-agent-win-generic:latest

This leads me to believe there's an issue in either the compose definition or in how the Docker Swarm handles the compose definition.

I've also tried using the credentialspec=raw://<json> version - the container launched fine but as before it couldn't access the network shares.

Any idea what's wrong?

I'm trying to set up a Docker container for our DevOps pipelines. I've... almost got it all.

Right now I've got a Windows-based container which:

1. has pre-installed SDKs, Java and the like
2. can manipulate (start, stop, build) docker containers
3. can access our network shares

The problem is that I can't get points 2) and 3) to be available simultaneously. To enable 3) I've had to prepare a group managed service account and the docker container needs to run as the NT AUTHORITY\NETWORK SERVICE. However, when the container IS running as NT AUTHORITY\NETWORK SERVICE it seems to lose access to the Docker pipeline.

Any idea how I can get both these things to work at the same time?

I've managed to get Docker set up on both a Linux and a Windows host in our organization for internal use.

Now I'd like to set up some "self-cleaning" DevOps worker agents; I've already got a Windows-based image of a DevOps agent prepared on the Windows host which has all we need for our internal build pipelines and which connects to our DevOps when started. Once started it'll keep running pipeline jobs until manually stopped. I can also use the --once flag when starting the agent itself to have it only process one job before shutting down (there's an issue with the script but it's unrelated to this question).

For reference I'm trying to set up what is generically described in this MS document:

If you want a fresh agent container for every pipeline run, pass the --once flag to the run command. You must also use a container orchestration system, like Kubernetes or Azure Container Instances, to start new copies of the container when the work completes.

My question is which on-prem orchestration systems would be able to handle re-creating the stopped containers, and which of them are "light" in terms of set up? Kubernetes is clearly mentioned, but it feels like a very big and complicated system to set up just for our internal DevOps pipelines (and tools like minikube and kind aren't really meant to be used with a Server Core host). Docker Swarm seems much easier to set up but I'm not sure if it can handle the scenario I have in mind.

We have 802.1x enabled for our wired connections and clients connect and authenticate fine (we also have a guest network for the unauthenticated).

That is - MOST clients authenticate fine. I have one Windows 10 machine that refuses to authenticate and looking at the client-side Wired AutoConfig logs I can see that it doesn't detect any need to perform 802.1x authentication with the error "Windows doesn't detect 802.1x authentication on wired network".

I know for a fact that dot1x is enabled on the port the given machine is connected to (I've even tried other ports in our network just to be safe). Enforcing 802.1x on the connection profile also doesn't help (in this instance our guest network becomes unreachable as well).

Any idea what could cause Windows to flat out not detect the 802.1x on the network?

A certain user (let's call him Bob) has reported issues using Remote Desktop when working with a new RDS Server I've set up. He reports "lag" that makes working with this server annoying, if not impossible. A coworker has, indeed, confirmed they saw this lag in action looking over Bob's shoulder. This lag has been described as a periodic freeze of the RDP image (~10 second freeze every few minutes), which seems like a connectivity issue.

Now, this new RDS has way more resources than an old one. It's a newer OS too (Windows Server 2019 Standard vs 2012 Standard), and is actually configured as a proper Windows RDS Server with licensing, as opposed to just a regular Windows Server VM with nothing on it.

Now, Bob has this issue regardless of where he is - he can be at the office using the WiFi, at home and connecting with VPN (we actually have two VPNs, one's using SSTP and the other OpenSSL). The only thing I don't know about Bob is that he's using his own PC rather than a company one to connect, and I've no idea how that's set up (don't ask - there's some office politics involved in this bit).

Since he's the only person reporting issues with the new server (I've been playing around with it, doing some heavy loads and all was fine), and the issue seems to be network-independent I'm thinking this has something to do with his PC or his setup.

Unfortunately, I'm drawing a blank on what that could be - I mean - he's connecting to a new server via RDP - what could possibly cause severe RDP connection lag to one machine but not another, even in a LAN environment?

Alternatively, this could be a connectivity issue... assuming it's possible for a given machine to periodically drop packets when connecting to one server, but not another (all on the same network). But, again, I'm drawing a blank here.

At the moment people from the company, who use company laptops at home, need to be connected via VPN to have Windows Update not throw errors, since the WSUS server is only for internal use.

I know it's possible to make WSUS public-facing; given it's, essentially, an IIS website, this is relatively simple (and should, hopefully, work with our firewall which offers a reverse-proxy).

However there are some thing I'm not sure of and I was hoping someone could clarify them:

• I've read that it's recommended to create a replica downstream server, and make THAT public-facing. Why?
• Are replica servers still recommended if I have a firewall capable of creating a secure reverse-proxy for local websites?
• Our main WSUS uses a regular SQL database (WSUS databases are notoriously annoying to manage and I can't imagine doing maintenance on them using only the "Windows Internal Database". Is the same true for replica WSUS servers?
• From what I can tell WSUS doesn't have any sort of "security", i.e. any computer which can access the DNS / IP and port of the WSUS server can use the service. How does this relate to, for example, setting up computers and computer groups in WSUS? I see nothing preventing someone from spamming a public-facing WSUS server with bogus computer information.

I've got... a strange customer request.

They have a specific custom site that requires authentication. I cannot make changes to this site.

They are showing a specific page from that site on a web-capable TV as a sort of "status panel". The problem is... they're annoyed they have to type in the login credentials every time the TV is powered on.

As such, I was thinking about creating some kind of reverse-proxy that doesn't use authentication (i.e. anonymous) and then passes on pre-fixed credentials when accessing the target site (if I recall the target site uses Windows auth). I could then set up Windows Firewall rules to only permit the TV access to the proxy (to keep things fairly secure).

Is such a thing possible in IIS? I know a reverse-proxy can be set up in IIS using Url Rewrite and Application Based Routing, but I'm not sure about the credentials bit (which, in the end, is the most important).

At the company we never really bothered with the root certificates and were under the impression this is something that's managed along with Windows Updates (and there's WSUS for that) and all was well.

However, today, I've noticed that a fresh Windows Server 2016 install, with all the updates, seems to have only very VERY basic root certificates, to the point where I can't even open Google (on account of not trusting their certificate).

(I haven't checked a fresh Windows 10 installation yet...)

I'm a bit confused by this, as this didn't happen before. Either we've made some poor changes in our GPOs (tho I can't think of anything that would have this effect), or this is something that was recently changed? How should I proceed so that things like Google can be accessed without issues? Do I need to manually add trusted certificates via GPOs now?

Here are some screenshots of what the situation looks like on a fresh server install.

I've been setting up off-site backups for the most critical elements of the company I work at. One of these critical elements is the DC.

Now, the company is fairly small, so has only a single forest, and two DC servers on separate physical machines (one's virtualized, however). That said, a critical fault in the server room could destroy both of these machines.

So, I'm trying to create a DC backup for a critical-case scenario. I keep reading online that backing up the System State is enough, but I have a feeling this is only valid if you want to be able to restore the DC on the same server where the backup was taken. I've tried taking a System State backup and then restoring it on an isolated VM (same server, same updates), and this... didn't go so well; the restore went fine, but then I couldn't contact the local DC, even if I ensured the VM had the same IP as before (still isolated, of course). None of the DC-related administrative consoles worked either. There was even a warning during restoration that restoring a System State from another machine is not suggested.

Thus, I feel this is the wrong approach. So... what IS the right approach, if I want to backup our DC off-site, to cover a critical failure? A complete backup of the C: drive + System State or I could just backup the whole drive for that virtualized DC, but I'm trying to make the backup as small as possible...

EDIT: I'm trying to make the backup as small as possible NOT to skip on costs, but on upload times.

PS. I'm using the Azure Backup application, but I don't think it's that relevant. All of our DCs are currently running Windows Server 2016.

Before I get into the details: my problem is clearly different than the one described in this question. I'm running a single Azure Connect instance, so the problem clearly isn't due to multiple sync. In fact, our system is using Azure Connect from the start, so there's no upgrade to speak of.

That said, pretty much every member of our organization had both a local AD account as well as a separate Office365 account. As such, in our case, the Azure Connect has to sync up to existing Azure AD accounts.

The process worked for most of our users; however, 9 accounts remain problematic, and I cannot figure out why.

The error message is pretty "standard":

Nie można zaktualizować tego obiektu, ponieważ następujące atrybuty skojarzone z tym obiektem mają wartości, które mogą już być skojarzone z innym obiektem w lokalnych usługach katalogowych: [Mail [email protected];]. Popraw lub usuń zduplikowane wartości w katalogu lokalnym. Więcej informacji na temat identyfikowania obiektów ze zduplikowanymi wartościami atrybutów, można znaleźć w artykule http://support.microsoft.com/kb/2647098.

Tracking Id: GUID ExtraErrorDetails: [{"Key":"ObjectIdInConflict","Value":["GUID"]},{"Key":"AttributeConflictName","Value":["Mail"]},{"Key":"AttributeConflictValues","Value":["[email protected]"]}]

The "friendly" part of the error message is in Polish, but it's the standard "InvalidSoftMatch" error.

Now, I know I'm using soft matching by SMTP address... but the user in question has a clearly defined email (via the email attribute in AD; we don't have a local Exchange to make use of the proxyAddresses attribute). That same user has the exact same SMTP address in Office365 Exchange (as well as a SIP address which is also the same). Needless to say, I can't find any other mentions of this email being used in Exchange online.

As such, I can't figure out why this account isn't being synchronized and keeps throwing the "soft match" error.

This question is, perhaps, slightly similar to this question, but the actual plan is different.

My goal is to create a "temp" share where people can off-load their data (for example, when they are getting ready to reinstall the OS or need to quickly share something with another employee).

Now, while a "temp" folder is by definition "temporary" and shouldn't be used for storing stuff long-term, I still want to maintain some security. To that end I'd like to grant my users (My.Domain\Domain Users) write access (create folders / files), and then modify / delete access only to the files / folders they, themselves, have created.

I suspect I'd need to make use of the "CREATOR OWNER" special principal. However, I feel that to restrict modify / delete capabilities, I'd need to explicitly add a deny permission to the NTFS security tab, and deny-rules, AFAIK, take precedent over allow-rules, so the CREATOR OWNER, even if granted full permission, wouldn't be able to actually make the changes.

Is what I'm trying to achieve at all possible?

I'm testing Azure AD Connect on a small "test" domain before I proceed with a full sync of our domain.

Unfortunately, I'm having some problems. Before I get to the problems, here's my setup:

• The name of the domain is NOT the same as the Azure domain, but an added UPN suffix IS.
• I've set-up AD Connect to sync only a single OU (for testing)
• The OU contains a single User with a manually specified email.
• The same user was created manually in Azure prior to starting the sync process. The Azure user was given an email licence, and an email address.
• Azure AD connect was set up with pretty basic settings. Password write-back was enabled as part of those settings. The system is set up to only sync that single OU specified earlier.

It appears that changing the test user's password in my local AD (and waiting for a sync) does update the password in Azure. However, the operation appears to be one-way, despite password write-back being enabled. Logged in as the test user I can request a password change without any issues (AND this new password starts to work for online logins), however this is never replicated in my local AD (old password works, new password doesn't).

There's an event log that happens at the same time the password is changed, but it doesn't really get me anywhere.

TrackingId: 5a76d0fc-3248-42b6-9a7a-cf8265766f38, HeartBeat for Namespace: ssprdedicatedsbprodscu, Endpoint: 3333b860-8fed-4146-aaeb-682401d60e10_2f466786-5627-462d-bcf7-ffc4bf83e8a0, Details: Version: 5.0.0.1541

I also tried to use the AD Connect troubleshooting portal, but that detected no faults.

Any idea how to proceed with debugging / fixing this?

We currently have an SSTP server (running on Windows Server 2008 R2 but it is being migrated to Windows Server 2016). At the moment, the server is configured using a wildcard certificate for one of our domains, lets call it *.olddomain.com.

As you can imagine from the example, the domain is old and we've already got a new certificate: *.newdomain.com.

The VPN is accessible via DNS entries for both of these domains:

• vpn.olddomain.com
• vpn.newdomain.com

Unfortunately, it seems that the SSTP configuration in Windows permits me to set up only one certificate. I COULD just switch to the new one, but then every client which hasn't updated the hostname will likely have issues connecting (the publisher of these certificates is publicly trusted, but I don't think a client accessing olddomain.com will be too happy to get a certificate for newdomain.com).

Is there a way to have both certificates running at the same time so that both hostnames can be used?

At the office we have an Intel Modular Server (v2 I think), and we're running low on storage space (all drive bays filled, and we're only using 3 compute modules on this thing).

As far as I'm reading the documentation and whatever else I can find online, the chassis has a SSF-8088 connector and should support expanders.

However, I'm not sure if just ANY expansion product with the above mentioned connector will work, or if only select few are compatible.

The documentation above lists a few specific vTrak products - however all of them are old enough that getting them might be more trouble than it's worth. However, at the same time, the products are mentioned somewhere inside the contents of the PDF - if ONLY these products are compatible, then I'd expect to find an explicit list somewhere... which I've not found thus far.

PS. I'm quite new to this storage-space-expanding-problem. If I'm using certain technical terms incorrectly or the question is obvious - I do apologise. Feel free to correct me and / or smack me with a trout.

Before I joined the company I work at, someone decided to make use of the 10.150.0.0/16 range for the company LAN (despite the company not having nearly that many devices). I think their idea at the time was to use the 3rd IP byte (10.150.X) to separate various infrastructure types while keeping them all on the same network. As such, critical hardware components (routers, APs, main HyperV hosts) are on 10.150.0.X, main servers are on 10.150.1.X, secondary servers seem to be on 10.150.2.X, and then there's the DHCP which assigns IPs from 10.150.3.1 to 10.150.4.254.

That's a pretty wide range, and quite frankly, it's a bit of a mess. Especially with the DHCP assigning IPs to everything from PCs, laptops, to mobile phones and even development servers.

I was hoping I could try and clean things up a bit. I'd like to make use of the NPS to set up various policies (so, for example, main domain servers would have a different policy than development servers and these would have a different policy from WiFi connected devices) and then use that information to assign different IP ranges. Except, I'm not sure if this is at all possible, given the wide net mask. Simply trying to set up a second DHCP scope for another IP range (say, 10.150.6.1-10.150.6.254) with the same netmask throws an error in Windows DHCP, which makes sense in a general way.

So, is what I'm trying to do at all possible? Or is my only course of action redesigning and reconfiguring the entire network?

Sometimes the proverbial excrement hits the fan and I need to reinstall the OS on a laptop or something. This isn't an issue.

Normally, I follow the following procedure:

• delete the computer from the AD
• reinstall OS
• set the host-name to match the old setting
• rejoin the domain

I'm wondering... what would happen (if anything) if I skipped the first step and just rejoined the domain with the same host-name?

I've got a domain running on Windows Server 2008 R2 - a bit old, sure, but it worked quite well.

Recently I've noticed that machines in the company seem to downloading updates from the Internet, rather than our internal WSUS server.

I've started to investigate, and I've noticed that the WSUS policies are not being applied (testing with rsop.msc).

The policies are correctly set up - after all, they WERE working before.

I wonder if this is because we have more and more systems running Windows 10, but that feels wrong, as I'm quite sure I've had my Windows 10 also download updates from the local WSUS a few weeks ago - you can sort of tell when that's the case when Windows shows that some settings are managed by a system administrator.

gpupdate /force runs without throwing any errors on the client machines as well.

Also, one specific GPO related to WSUS is still working - it sets up client side targeting.

What could be wrong? How could I try and debug these WSUS-related GPOs?

Recently our internal SMTP relay server stopped working - or rather, stopped sending emails. It responds to send mail requests, a simple TELNET session shows no errors, but all messages get stuck in its queue.

This all happened after our virtualization server ran out of disk space and suspended quite a few machines.

I suspect this is a DNS issue. I was able to set up a working relay server inside a virtual machine (on my own workstation), but I had to configure 8.8.8.8 as the DNS server for that machine.

As soon as I reverted to our DHCP assigned DNS my own mail server would stop.

Unfortunately, there appear to be no useful logs whatsoever. I don't know if the mail server is having issues resolving some domain name or connecting to some IP. On my virtual machine with Google DNS the log contains send message requests followed by a set of messages for relaying - i.e. connecting to another mail server and forwarding the email. On the actual server where the issue occurs there are no messages regarding relaying.

Unfortunately, the machine hosting the mail server is also the primary DNS machine for our internal network (don't look at me, I didn't set that up), so I cannot just use Googles DNS and call it a day - doing so I'd probably break a lot of other things.

Any idea what could possibly be wrong? Alternatively - is there any way to find find out what is the EXACT reason messages aren't leaving the queue folder?

Here's a scenario that occurs quite frequently.

Before installing system updates I create a snapshot of a virtual machine in case something goes wrong. After the update is done and there are no problems, I want to remove the snapshot, as it would just be taking up space otherwise.

This means I need to turn the machine off (either completely, or save it). No issues there.

My gripe is that after saving the machine, I need to wait for the merge to complete (and depending on how many updates there were, this can take some time) and then manually bring the machine back up. I know Windows Server 2012 can perform merges when a machine is running, but we're using Windows Server 2008 R2.

Is there any way to have Hyper-V automate this process? I mean - bring the virtual machine up after merging, so I don't need to sit and wait around?