r/WindowsServer

Hi everyone,

I got tired of deploying my customized Windows image (built with NTLite) via USB stick, so I started looking into PXE boot and network-based OS deployment. Honestly, I'm pretty frustrated by now.

I tried WDS, but as far as I can tell, Windows 11 deployment with boot.wim is blocked, MDT is retired, and WDS itself is being deprecated.

So how are you guys doing this nowadays? What's your setup for deploying a custom Windows 11 image over the network?

Thanks in advance!

Hi, my wsus servers has stopped receiving new defender definition updates. Last was 06.10 and no clients receive updates because of this. From what i can see there has been no change on the wsus or config anywhere else.

Has anyone seen this behavior before?

Last synced version i can see on my wsus is 1.459.588.0

Edit: Last synced version i can see on my wsus is 1.459.576.0

Edit2: Its solved, syncing now

Every serverless pitch skips the driver part.

1,800 users, eleven sites, mostly Ricoh with a handful of Xerox left over from an old contract. Going direct IP. What's stalling the business case isn't the queues, it's what happens to drivers once nothing is handing them out centrally. Looking at printerlogic, now Vasion, plus uniFLOW, LRS and Pharos. All of them say drivers get easier. None of the product pages say how.

v3 versus v4 is a known headache and I'd rather understand it before signing anything. Genuinely curious whether it got simpler for people who've already done this, or whether the work just moved somewhere else.

hello i have a problem, when i try to install windows server 2019 on hpe proliant dl380 gen 9 every time i try to get past windows setup before i even have a chance to get to the storage part i get a error saying „windows setup could not install one or more boot drivers to install windows make sure that the drivers valid and restart the installation” i tried installing HPCISSS3 drivers i have raid 5 on my three hdds and when i try to install it thru the f10 menu directly from iso it doesnt even let me select it please help

Hi everyone,

I’m setting up a new Active Directory environment on Windows Server 2025 Standard and I’m stuck with a strange login issue after promoting the server to a domain controller.

Server details:

• Windows Server 2025 Standard
• Server name: GC-DC01
• Static IP: 192.168.8.244
• Domain: ad.generalco.local
• NetBIOS domain name: GENERALCO
• DNS installed on the same server
• This is a new forest/domain
• Server was previously a standalone Windows Server

Before promotion, I could log in normally using the local Administrator account and the password was working.

I then promoted the server using PowerShell:

Install-ADDSForest `

-DomainName "ad.generalco.local" `

-DomainNetbiosName "GENERALCO" `

-InstallDNS `

-SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM Password") `

-Force

The promotion completed successfully and reported:

Operation completed successfully
Status: Success

The server rebooted.

Now at the Windows login screen it shows:

GENERALCO\Administrator

However, the same Administrator password that worked before the promotion is now rejected.

I have also tried:

GENERALCO\Administrator
Administrator@ad.generalco.local

Both reject the password.

I understand that the DSRM password is separate from the normal domain Administrator password. I am not using the DSRM password for the normal login.

The strange part is that the password worked immediately before the AD promotion, and the AD promotion itself completed successfully.

I currently cannot get into Windows normally, so I cannot open PowerShell/CMD from the desktop.

I have physical access to the server (HPE ProLiant DL380 Gen11). F11 only gives me the HPE One-Time Boot Menu.

Questions:

1. What could cause the Administrator password to stop working immediately after AD DS promotion?
2. Is there a supported way to recover/reset the domain Administrator password in this situation?
3. Can I use the DSRM password to get into a recovery environment and repair the domain Administrator account?
4. Is there anything I should check in WinRE before considering rebuilding the domain?

I would really prefer to recover this installation rather than reinstall Windows, since the AD DS/DNS promotion itself completed successfully.

Any advice from someone experienced with Server 2025 AD DS would be greatly appreciated.

I just wanted to post a brief apology to our community members for the very annoying "Subscriber Goal" post that was pinned to the front of the sub for some amount of time recently. It was not created or intended by any of the mods, but rather by an automated moderation tool that is part of the larger Reddit community mod tool suite. It had been purposely disabled in the past, but not completely removed from the sub. Unfortunately, as part of a recent update that was made to this tool, it appears to have been automatically reenabled without our consent, and I failed to notice it quickly enough to prevent it from rather aggressively annoying a number of you all out there in the community. I apologize for the oversight.

I'd like to also reiterate that none of us on the moderation team here have any interest in pushing a pursuit of additional subscriber numbers, especially not for the sake of social media metrics. We believe the entire value of this community comes not from flashy metrics, subscriber stats, or view counts, but only from legitimate, contributing subscribers like so many of you here have been over the years. Living, breathing people who with "boots on the ground" every day that are passionate about IT and generously sharing your experiences and knowledge gained through the challenges faced in the field.

We appreciate you guys and gals more than you know.

Hi, we're seeing a strange permission/access behavior on some of our Windows Server 2022 file servers and I'm trying to figure out what could be causing it. We're running an AD domain environment. My account is a member of an AD security group, and that security group is a member of the local Administrators group on the file servers. Administrators have Full Control on the relevant NTFS folder structures. When I access a file server from my workstation through Windows Explorer using \\fileserver\share\folder, I can browse through the entire folder structure without any issues. However, when I'm logged onto the file server itself and try to access the same folders locally through Windows Explorer using D:\share\folder, Explorer denies access unless my user account is explicitly added to the folder permissions. The strange thing is that the permissions themselves clearly work. On the same server I can access the folders via CMD without any problems, applications such as our backup software can access them, and remote SMB access from my workstation works as expected. The issue seems to affect only Windows Explorer when it is running locally on the affected file server. I compared this with one of our web servers. The AD group membership, local Administrators setup, NTFS permissions and UAC level are essentially the same there, but local Explorer access works normally. One additional difference that might or might not be relevant is DFS. The affected file servers are using DFS, while the web server obviously isn't. I'm not sure yet whether DFS itself is involved, but since this is one of the differences between the affected file servers and the unaffected server, I thought it was worth mentioning. I vaguely remember this behavior appearing after a Windows Server update, possibly around the move to Server 2022, but unfortunately I can't say for certain when it started. Has anyone seen this specific behavior before, where access granted through the local Administrators group works via CMD and remote SMB but fails specifically in the local Windows Explorer? I'm particularly interested in whether there was a Windows Server 2022 security change/update, a DFS-related behavior, or a specific UAC/security policy that could cause this. I'd rather understand the underlying cause than work around it by explicitly adding individual admin accounts to the NTFS permissions.

I used ChatGPT to help structure and phrase this post so that the issue is described clearly and coherently. Apologies if the wording comes across a little too polished or AI-assisted.

We have an issue with our two different AD domains.
The servers added to both domains change their time to few months in future. It is intermittent we haven’t been able to identity similarity between the affected servers
It happens only once to a server. We have already disable secure time seeding per MICROSOFT recommendation.

Time authority is domain controllers. We have multiple data centre providers and it is happening everywhere. There is no consistent time as well randomly happen sometime thrice a month sometime once.

Ran out of troubleshooting steps. This issue is causing our scheduled jobs to fail.
Any troubleshooting steps would be appreciated

I've spun up a Server 2025 box to act as a new print server to replace our 2016 box. I migrated all of the print queues over using the migration tool and I'm having issues with a specific driver for our Fiery devices. We're also using Uniflow to ensure people are physically at printers to release their print jobs.

We're using the Canon iPR Svr M20 PS V1.0 US version 6.5.0 driver which is deployed to all machines via SCCM and we map the printers using group policy. On the server 2016 mapping queues to client machines running Windows 11 24H2 using this driver works as expected, however with server 2025 mapping to those same client machines gives us a UAC prompt to install the driver despite it already been installed on the client. Changing the driver on the queue to the Canon generic driver allows the queue to be mapped to the client with no prompts. I've replicated this issue on a test Server 2025 instance and I'm seeing the same results. Comparing the installed driver files on the server and client I'm not seeing any differences to explain why the server things a install is necessary for this particular driver. Was hoping someone may be able to shed some light on this one.

Thanks.

I am troubleshooting a Windows Server 2016 file server with a very busy Security event log.

The log was growing to almost 10 GB and receiving thousands of events every few minutes. Most were event 5145 for Detailed File Share auditing, along with 5156 and 5158 Filtering Platform events. The Event Log service was also using noticeable CPU.

Auditpol shows these settings enabled:

Detailed File Share: Success and Failure

Filtering Platform Connection: Success

File System: Success

I disabled these settings through Local Security Policy, but auditpol continued to show them enabled.

I created a separate domain GPO scoped only to this server. I configured Detailed File Share, File Share, File System, Filtering Platform Connection and Filtering Platform Packet Drop as No Auditing. I also enabled the setting that forces advanced audit subcategories to override legacy audit categories.

The GPO applies successfully according to the Group Policy operational log. I moved it to the highest link order and confirmed that the server receives it.

I discovered that Default Domain Policy was missing its audit.csv file. I recreated it by temporarily configuring an Advanced Audit setting and then returning it to Not Configured. I also rewrote a setting in the new server specific GPO so its audit.csv would be regenerated.

I confirmed that both GPO audit.csv files contain value 0 for the five settings.

I archived the local audit.csv file and the active cached copy under C:\Windows\Security\Audit. I then forced Group Policy again.

I backed up the complete audit policy, ran auditpol /clear, and forced Group Policy to rebuild it.

I also removed an old auditing entry from the root of the shared data folder. It audited Domain Users across the folder, all subfolders and files. Removing that entry successfully stopped event 4663, but event 5145 continues because Detailed File Share auditing keeps turning itself back on.

Direct auditpol commands temporarily change the settings to No Auditing, but Windows restores Detailed File Share, Filtering Platform Connection and File System within seconds.

I tested with the remote management service stopped and ruled that out. Antivirus does not appear to be causing it. I also tested a SYSTEM scheduled task that repeatedly ran auditpol, but Windows restored the settings faster than the task could maintain them.

For now, I reduced the Security log to 256 MB and configured it to overwrite old events automatically. The server and file shares are operating normally.

Has anyone seen Windows Server 2016 continuously restore these Advanced Audit settings even though Local Policy and all applicable domain GPOs show No Auditing? Is there another audit policy database, security template, service or registry location that could be enforcing these settings?

-lee