<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Windows Server on Network Haven</title>
    <link>/tags/windows-server/</link>
    <description>Recent content in Windows Server on Network Haven</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 13 May 2026 12:00:00 +0200</lastBuildDate>
    <atom:link href="/tags/windows-server/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Fixing SCEP Certificate Enrollment over HTTPS on eLux Thin Clients</title>
      <link>/posts/2026/fixing-scep-certificate-enrollement-over-https-on-elux-thin-clients/</link>
      <pubDate>Wed, 13 May 2026 12:00:00 +0200</pubDate>
      <guid>/posts/2026/fixing-scep-certificate-enrollement-over-https-on-elux-thin-clients/</guid>
      <description>&lt;p&gt;Currently we trying out eLux as an replacement of older thin clients with ThinOS or IgelOS. We tried to configure 802.1x authentication and the therefore needed certificate enrollment with our current SCEP/NDES server. We came across the issue that the scep client that eLux uses – &lt;a href=&#34;https://github.com/certnanny/sscep&#34;&gt;sscep&lt;/a&gt; – an open source “Simple SCEP client for Unix” &lt;strong&gt;doesn’t support certificates requests over HTTPS&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;When investigating the problem we found this GitHub issue which explains our problem. Our NDES server was only reachable over HTTPS – both on the administration page and most importantly also on the request web page (certsrv/mscep) where the client requests their certificates.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to manually import WSUS updates in an air-gapped environment</title>
      <link>/posts/2026/how-to-manually-import-wsus-updates-in-an-air-gapped-environment/</link>
      <pubDate>Tue, 21 Apr 2026 23:10:03 +0200</pubDate>
      <guid>/posts/2026/how-to-manually-import-wsus-updates-in-an-air-gapped-environment/</guid>
      <description>&lt;p&gt;Since 2023 you could not import updates manually to WSUS. Microsoft offers you a &lt;a href=&#34;https://learn.microsoft.com/en-us/windows-server/administration/windows-server-update-services/manage/wsus-and-the-catalog-site?branch=pr-4097#powershell-script-to-import-updates-into-wsus&#34;&gt;script&lt;/a&gt; to download the updates from the update catalog when you provide the &lt;strong&gt;UpdateID&lt;/strong&gt; to the script. The script defaults to localhost if you dont provide the WSUS server. For example:&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-powershell&#34; data-lang=&#34;powershell&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;p&#34;&gt;.\&lt;/span&gt;&lt;span class=&#34;n&#34;&gt;ImportUpdateToWSUS&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;.&lt;/span&gt;&lt;span class=&#34;py&#34;&gt;ps1&lt;/span&gt; &lt;span class=&#34;n&#34;&gt;-UpdateId&lt;/span&gt; &lt;span class=&#34;mf&#34;&gt;12345678&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;-&lt;/span&gt;&lt;span class=&#34;n&#34;&gt;90ab-cdef&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;-&lt;/span&gt;&lt;span class=&#34;mf&#34;&gt;1234&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;-&lt;/span&gt;&lt;span class=&#34;n&#34;&gt;567890abcdef&lt;/span&gt;&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;But this script has a big issue for air-gapped enviroments – it still relies on the microsoft update catalog to download and import it to the WSUS server. But in the background the script just uses the &lt;a href=&#34;https://learn.microsoft.com/en-us/previous-versions/windows/desktop/bb530766%28v=vs.85%29&#34;&gt;ImportUpdateFromCatalogSite()&lt;/a&gt; powershell function. If you look at the parameters, you can parse the UpdateID but also “an array of the local paths where any files required by the update can be found.”&lt;/p&gt;</description>
    </item>
    <item>
      <title>Issue detecting domain network on domain controller when using NIC teaming</title>
      <link>/posts/2026/issue-detecting-domain-network-on-domain-controller-when-using-nic-teaming/</link>
      <pubDate>Fri, 10 Apr 2026 23:10:03 +0200</pubDate>
      <guid>/posts/2026/issue-detecting-domain-network-on-domain-controller-when-using-nic-teaming/</guid>
      <description>&lt;p&gt;We had an issue where our domain controller lost its domain network profile after a reboot. When it came back up it was set to public instead of domain.&lt;/p&gt;&#xA;&lt;p&gt;The problem occurred only when Windows NIC teaming (switch-independent) was used in combination with two network adapters in the team. As soon as one network adapter was disabled from the team (while the other remained active), the network profile (domain) was recognized correctly.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
