It´s a late announcement, but I´m happy to tell the world that I´ve been accepted to speak at Experts Live in Prague November 20-22!
It will be my first Experts Live, but from what I´ve already have experienced in terms of organization and how they´ve have handled me as a speaker – I´m VERY excited!
Ill be presenting a session on Windows Virtual Desktop and how it integrates and enhances (and gets enhanced) by Microsoft 365. A session I´ve presented a number of times and that always gets the attendees to think in new directions and understands how WVD is democratizing End-User Computing.
I´m of course happy that Alexander have been accepted as well and will present two sessions as well.
Other than that I´m of course looking forward to the keynote with Joey Snow and Rick Claus of Patch & Switch fame as well as sessions from Marius Skovli and Alexander Benoit among others! You can check out all the sessions in the session catalogue which you can find here:
But don’t forget what conferences are all about, its learning and connecting. Therefore it will be great fun to spend so much time socializing with all the speakers and attendees during the different networking events. So take the opportunity to reach out to me before or during the event. Perhaps we´ll even invite you to be a part of our Knee Deep in Tech podcast? 😀
Looking forward to seeing you in Prague!
Hey there. Toni here back with some thoughts on domain controllers and their local SAM database. You know, the thing that is disabled as soon as the server is promoted to a domain controller.
This is something that is often forgotten about until it’s too late. This database is actually critical if something bad happens to your active directory. Do you know the local admin password on your domain controller? How long ago since it was installed? The local admin password is set when the domain controller is promoted. Did you promote it? Did a consultant? Do you even know the password?
This local admin account comes into play when the domain controller needs to start in DSRM, or Directory Services Restore Mode. This is done when the house is on fire and no one can do anything. So is this the time when you don’t know the local admin password and need to find someone who does? I would guess no, since you are probably under enough stress at this moment anyway. Here is a quick guide on how to reset the local admin password on a fully functioning domain controller.
Run CMD as Admininstrator, type ntdsutil [Enter]
Next we switch to the Reset DSRM Password context.
Set d p [Enter]
Then we select which server to set the password on.
r p o s servername [Enter]
Enter your password and you’re done.
Now you are ready to restore your AD in case of emergency by starting the server in DSR Mode.
Hey folks, long time no see. How are you doing?
In Episode 80 of Kneedeepintech I briefly mentioned Windows Server and gaming in the same sentence. Now that I have had time to actually test it again I’d thought I would post my findings here.
I have the Xbox 360 wired controllers that I’ve used plenty with Windows 7/8/10 but wanted to try and play on Windows Server 2012R2 previously. No luck back then. The controller would not light up at all complaining about driver issues.
So now I tried this again with Windows Server 2019. Same issue. No light, unknown controller and no drivers to be found online.
I check my Windows 10 1903 box in device manager what the driver files are for the controller and found that there was only one called “xusb22.sys” located under “\Windows\system32\drivers”
I copied that file to an empty folder knowing that I would also need the .inf file which I found under “\Windows\inf” with the name “xusb22.inf”. There was also a “xusb22.PNF”, so I copied that too.
Next I went back to my Windows Server box, device manager and just clicked on “Update driver” on the unknown controller device. This time Windows said that it found a matching driver but it was not signed properly. Ah, now we’re getting somewhere.
Now, I rebooted the server and pressed F8 for start-up options, since there is a workaround there for signed drivers. Select the option to disable driver signing check. Once back in Windows I went for device manager again, selected Update driver and this time I got a warning with the option to install anyway. Boom, the controller lit up. Hey hey!
Then I needed to test it out. I installed Steam and downloaded the games Braid and Limbo since I don’t have a hefty graphics card in said Server. Launched the games and both worked fine with the controller. Victory!
You can download the files here: xusb22
Hey. Today I want to talk about an interesting case that involves Kerberos, Always On VPN and access to CIFS.
A customer has recently deployed Always on VPN in their infrastructure. Most clients worked well with that but a few had mixed issues with old VPN clients installed on some machines.
Cisco AnyConnect usually worked fine when installed, but there was another VPN client that disabled the IKE/EXT service which prevented the AO VPN IPSEC to work properly. So uninstalling that software solved the issues. The customer still had that installed on some clients as a backup solutions for when IPSEC was blocked at the source (for example hotels, airports etc.)
But hey! I mentioned Kerberos, how does that come into play?
Disclaimer: This post has might have little to do with Always On VPN, but the issue manifested itself when connected through AOVPN.
Well, there was a few clients that actually connected fine. They could ping stuff on the network and everything seemed fine until they tried to access the file server. They got prompted with credentials stating that they had no access to the domain controller even though I could actually get LDAP access with AD-powershell, so LDAP was obviously working. This was interesting. After a few log checks on both sides of the fence, nothing popped out. So I decided to install Wireshark on the domain controller to try and figure things out. This gave me lots of new and critical information.
I could clearly see that Kerberos was not working. UN_SUPPORTED when the client tried to get a Kerberos ticket from the KDC. So I checked the DC logs and found issues with the Kerberos certificate.
Sorry for the lack of screens, this all happened really fast and I was definitely not allowed to screenshot the customers data.
It turned out that the domain controller was using previously issued certificates from and old and retired Certificate Authority. So I deleted all of them and issued the domain controller new certs for domain controller authentication and Kerberos authentication. Now my senses were tingling since I knew that this would fix the problems. And lo and behold, it did! The troubled clients worked right away.
But, one thing was still bothering me and is still bothering me. Since this was a server side fix, why did not all the clients have this issue? Why was only a select few clients using Kerberos auth? The customer is telling me that all computers are equal and installed from the same image and are getting the same policies. So why are only a select few using Kerberos (that failed). At the time of writing, I don’t know. This happened just recently. Maybe you have some ideas? Feel free to contact me on twitter (@mrblackswe) or post a comment below. Something tells me that the clients are not equal at all, despite what the customer is telling me (Usually the case). The clients are Windows 10 Pro 1809, afaik.
Good day to you. Today I’ve done a little write-up about my home lab equipment. I was noticing a few slowdowns once I got around 10 vm’s running on my old “server”, which was an older gen Intel E3 1240 series CPU running 32Gb of DDR3 RAM, SSD cache and spinning HDDs for mass storage. Since the stuff was closing in on 5 years of service I thought it was time to invest in some new hardware.
This time I decided to go AMD and specifically the Threadripper 1920X with 12 cores/24 threads and 64Gb of DDR4 memory. So I doubled the RAM amount and also the RAM speed and the core count tripled with higher clocks as well. All flash this time as well did it’s thing for sure as there are now 5 SSD in a combination of SATA and M2 drives in RAID-0 hosting the VM’s through storage spaces. As far as I know, the only limitation of running Hyper-V on Threadripper is that it can’t do nested virtualization, but I haven’t verified that myself yet as it is a feature I don’t specifically need.
I did not invest in networking at all since I don’t really need more that 1 Gbit externally from the host. Everything else in my network runs a singe NIC except for the NAS, which cannot get to line-speeds anyway despite having 4 ports. I could always get a 10Gbit addon-card later if needed.
So, once the new work horse was built and Hyper-V installed, it was only a matter of settings the constrained kerberos delegations correctly and start migrating machines. Live-migration was out the window due to CPU differences so I had to make the VMs “Migration enabled”. This is done for example with Powershell:
Set-VMProcessor -VMName NameOfVM -CompatibilityForMigrationEnabled 1
Note that the machine has to be turned off for this to run correctly. Once I’ve run the Move-VM command, I just run the above command again with -CompatibilityForMigrationEnabled 0 and the move was completed.
The new machine feels very much faster than the old one and a new install of WS2019 w/ desktop from the MDT took just 4 minutes to finish. I may do some iops testing further down the road but I expect that the numbers are pretty good for consumer/workstation grade hardware.
Hey, the Finn here again with another random post.
A client reached out to me since they are in the process of switching print servers. They have a lot of printers, to say the least. They are all managed manually and they felt that they would like avoid the hassle of creating all the print queues manually on the new server. Powershell to the rescue!
They gave me a list with desired things that the script should do. I might have over delivered on that, but I like Powershell. It’s freaking awesome for so many things in Windows and beyond.
So, let’s have a look at what I did. Script full of comments for explanation ofc and split in regions for easy reading.
Since we will be dealing with installing printer ports, printers and DNS-records, I figured it might be a good idea to check that the script is “run as admin” or just end it right there.
Once that is out of the way we need to establish some customer specific variables such as the input file (CSV), the DNS server name, the zone in which to create the record and lastly the template printer that we want to use for custom settings.
After the initial variables now defined and checked by the script, we can move on to creating the actual functions that do stuff. So first we create the DNS-record.
This requires the DNSServer RSAT module to be installed on the machine running the script and you will not be able to run at all if that is missing since the script actually checks for that as well. However, this is really easy with Windows 10. Just run this powershell command: Add-WindowsCapability -Name Rsat.Dns.Tools~~~~0.0.1.0 -Online and you are all set.
For the next portion of the script, we’ll need to create the network port on which the printer resides. We’ll get som in-data from the CSV that we utilize here. We’ll do a try/catch approach. Also, we will try to create the printer itself right after. Log to screen and file if something goes wrong.
Now, we have the printer created and ready to go. Now we will set the permissions on it from the template printer and also any other settings that are presented in XML from the originating printer.
That would be the last step in this excercise of the functions. Now, onto the trigger of the whole thing.
We do some basic checks before kicking things off. Making sure that there is a template printer, that we have the necessary powershell modules we need and also that the input-csv actually exists, before doing anything else.
Lastly we store the variables as arguments to send to the different functions and voilá, the script is done.
Feel free to comment all of my mistakes. Download file here.
Hey there. The Finn here with another little quick update. This time on Windows Admin Center and certificates.
You are using Windows Admin Center, right? It’s good stuff. You like good stuff, right?
Self-signed is the default option, but man is that an ugly way to go.
Here is how you update your Windows Admin Center certificate without any third party tool.
Open up Powershell, run dir cert:\localmachine\my to get a list of installed certificates.
Copy the thumbprint for the certificate you want to use.
Then we will check for the application ID that WAC uses and the port it is bound to (Default is 6515) with netsh http show sslcert
Once we have the new thumbprint and the appid, we can go ahead and delete the existing certificate binding, again with netsh http delete sslcert=0.0.0.0:6515 (or the port you are using)
An finally we can bind the new certificate to the WAC port.
And that is all there is to it. However… I saw a retweet from my MVP friend Andy Syrewicze who linked to a colleague of his who wrote a little handy tool that does this switch-a-roo as well.
You can find that tool here: https://etechgoodness.wordpress.com/2019/02/28/announcing-windows-admin-center-certificate-selector/