The IT Crownd

When importing an Windows 10 image from the Media Creation Tool I was seeing the error "the source directory specified does not contain an identifiable operating system" This is because MDT needs a WIM image not an ESD image which MCT uses. Nice.  Not. To convert an ESD image file to one useable by MDT you need to complete the following. Log into your machine as Admin Install and create a Windows 10 build using the Media Creation Tool straight to USB Install Deployment and Imaging Tools onto your MDT box (unless you have it already!) Run Deployment and Imaging Tools Environment as Admin Type and run the following to list all the OS's in the ESD file dism /Get-WimInfo /WimFile:<path to install.esd> Find the OS you want and note down the Index Then run the following dism /export-image /SourceImageFile:<path to install.esd> /SourceIndex:<INDEX> /DestinationImageFile:<path for install.wim> /Compress:max /CheckIntegrity

We are rolling out Citrix and wanted to use the email discovery - whilst this has issues due to our choice of network IP addresses (don't ask!) I found a couple of web pages which assisted in getting this sorted. https://www.jgspiers.com/configuring-citrix-receiver-email-based-discovery/ https://www.virtualexperience.no/2012/08/25/configure-citrix-receiver-email-based-discovery/ I only have need for this process internally as we are not running netscalers.  Yet.  So my DNS requirements are somewhat simplified. This all boils down to three things. an internal SRV record for _citrixreceiver._tcp.domain.com port 443 a certificate from internal (trusted) PKI with a SAN of discoverReceiver.domain.com - I used a web server template and included the FQDN as CN and FQDN, shortname of the server and discoverReceiver.domain.com as SANs install this certificate into IIS default website - or whatever website you are using to host the Store.  Change "domain.com" to

Oh dear. We implemented site wide 802.1x when we moved. This has caused numerous issues which we are still tracking down and killing with fire. Again "only-when-we-needed-it" struck as we had a new starter and need to build a machine. Ah.   No PXE.  However thankfully we were able to make a bootable USB using 802.1x and get our build working again from MDT in our 802.1 environment. Here's how we did it.   Caveats:  I'm assuming you know MDT and how PXE works. We use Computer certificates as the 8021x auth method. 802.1x is working in our environment GPO is used to start the wired 802.1x service on built machines. GPO is used to configure the network profile to use 802.1x What you need Get a USB stick to take your WinPE 4GB may be enough Make sure you are running an up to date working MDT installation! Create a machine certificate which has a long expiry date, you don't want to be making USB WinPE images every month!! Export the machine

Recently our SQL servers broke. Big time. Totally unrecoverable. This box "only" ran small infrastructure databases. MBAM being the main one. We only noticed when we needed to unlock a bitlocker locked machine and MBAM wasn't responding.   Our backups we toast too as the SQL server box had been unusable for longer than our retention period and we now had backups of a broken machine. Not great.  We now monitor this server.  Like a hawk.  Horse. Bolt. Stable.  Oh well.  We did have the data on separate disks so we were able to get the bitlocker database itself back and mount this on a new SQL box so not all lost. We took this opportunity to upgrade MBAM and the MBAM client we delivered to the end points. Then Windows 1903 was released and we began piloting this to certain users.  Due to the recent "interest" in MBAM we noticed that bitlocker was not enabling on these machine despite the GPO being in place. This GPO worked fl

Our VPN solution is based on RRAS running on Windows Server 2016 running on ESX 7.5, through a Fortinet Firewall. For a while we've been having VPN connectivity issues.  Users who could connect one day were failing to connect or connections were dropping.   It is your typical IT nightmare - nothing changed in either client or server config and things just worked or failed randomly. It got so bad (Execs got involved!) and we are now implementing a new solution and moving away from RRAS. In any case I began last month by finally "giving-in" and rebooting the servers each night (I've an Orchestrator job which checks the VPN connections and reboots the server if there are none) This seemed to help and connections were a lot better. I did some more trawling the internet and found some really old posts that VMXNET3 adapters caused issues with RRAS and NAT (which I am doing)  So I reconfigured to use E1000. Again another level of stability!   Finally I remembe

Messing around with VPNs last week I found that it is easier (sometimes) to have a one liner for VPN creation! Here's how I make a PEAP\MSChapV2 VPN profile...using the users Windows creds! Change ServerAddress, DnsSuffix and choose a better L2tpPsk!! $a = New-EapConfiguration -UseWinlogonCredential $b = New-EapConfiguration -Peap -TunnledEapAuthMethod $a.EapConfigXmlStream Add-VpnConnection -Name "VPN (SSL)" -ServerAddress vpn.fqdn.com -AuthenticationMethod Eap -DnsSuffix my.domain.com -EapConfigXmlStream $b.EapConfigXmlStream -EncryptionLevel Maximum -Force -RememberCredential -AllUserConnection -TunnelType Sstp Add-VpnConnection -Name "VPN (L2TP)" -ServerAddress vpn.fqdn.com -AuthenticationMethod Eap -DnsSuffix my.domain.com -EapConfigXmlStream $b.EapConfigXmlStream -EncryptionLevel Maximum -Force -RememberCredential -AllUserConnection -TunnelType L2tp -L2tpPsk "shared secret key"

We have a pair of 2019 core servers running our file shares. We also use System Center Orchestrator to automate some things. Here is how I set up Orchestrator to take initate VSS snapshots. Ensure that VSS is running ok on your fileserver and you can manually take a VSS snapshot - using vssadmin. Decide on your schedule - we do a snapshot every 2 hours. Create a Monitor Date/Time step configured to the required VSS schedule I found the only way to get VSS to run correctly was using PSEXEC to run the actual VSS snapshot  So make a Run Program step for each File Server, to run the following command line (replacing values where needed) psexec.exe -h -accepteula \\fileserver01 vssadmin create shadow /for=F: M ake sure you enter an account in the Advanced and Security sections.  The account needs the correct permissions to create VSS snaps on the fileservers! I then do some error checking and logging based on this with failures also raising an email notification

Ran into an issue where I needed to "double-hop" from one PSSession to another. This led to an investigation into how to set up CredSSP My issue resolved around getting System Center Orchestrator to run some PowerShell which reports back the number of users currently on our VPN server. I followed the awesome posts from * where they suggest to run a PSSession onto the localhost (in my case Orchestrator) rather than to run PowerShell.  This is cool unless you then want to PSSession onto another box, in my case my VPN box to run some more PowerShell! The post does briefly mention setting up WSManCred - too briefly ;) Anyways on the first hop machine you need to run (as Administrator) the PowerShell - replace *.domain.com with you domain name - or for tighter security replace with the FQDN of the target server. PS C:\Enable-WSManCredSSP Client -DelegateComputer *.domain.com And on the second hop computer... PS C:\Enable-WSManCredSSP Server -Force At any time you

Had some trouble with our ESX VMs booting to the Windows Deployment Server when using UEFI. UEFI is now the default boot for VMs - finally! Changing the network interface from VMXNET3.0 to E1000e made things work again!  We had Secure Boot enabled in both cases. Our physical devices (DELL Latitudes) have no issue so we suspected ESX. Devices with VMXNET interfaces were failing to boot, get DHCP or anything....they just (seemingly) timed out. Turns out, for us it was a TFTP configuration. In WDS right click your WDS Server node and open the properties dialog.   GO to the TFTP config tab and set the following Disable : Enable Variable Window Extension Configure: Maximum Block Size to 16384 Worked for us. Thanks to fboehme (although I see Secure Boot is disabled in this post!) https://communities.vmware.com/thread/572481?start=15&tstart=0

Windows 10 has a nice feature called Always On VPN. This is pretty much an acceptance that many people have not deployed Direct Access :)  Although DA is not a VPN solution I prefer AO so I set it up for our recent Windows 10 roll out. Basically the steps boil down to... Create some certificate templates. Create 2 new VMs. Enroll into those templates Install RRAS and NPS roles Config RRAS and NPS Client Config The most difficult for me was deciding on how to get the client config to roll out.  We use the Quest appliance KACE here so I used that to deploy a powershell script which sets up the VPN.  Love Windows 10!! I used MDT to build two Windows 2016 servers - I tried the core but my skills were not up for it! EDIT: It is not possible to install NPS on core - it does "come with" RRAS but avoid on core! EDIT:  I ended up making my NPS and RRAS box the same it reduces the server count a bit and proved more reliable/stable (Never found out why)