Over the years I’ve had many issues where a Windows client PC just won’t connect to a share using the FQDN, but can connect using the NetBios name. There have also been plenty of occasions where the opposite is true, too.
I had the issue again today on a freshly-built Windows 10 machine. Folder redirection wouldn’t apply because the user’s desktop folder was inaccessible.
Then I came across this post on the Spiceworks forums that mentioned resetting the CSC database. I tried that, and folder redirection now works perfectly!
If caching is enabled on the share in question, and the CSC database is knackered, you’ll run into this same problem.
If only I’d known about this earlier in my 15-year IT career, it could potentially have saved a lot of headaches.
Add the following reg key/value. then reboot the PC:
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Csc\Parameters /v FormatDatabase /t REG_DWORD /d 1 /f
I’ve got a bunch of older SOE machines that still had the local Administrator account enabled. As part of implementing Microsoft LAPS, I wanted to disable that account, and use a newly-created ‘LocalAdmin’ account with LAPS.
The account is created with a randomly-generated GUID as the password. The account’s password is going to come under the management of LAPS anyway. Additionally, it would be a terrible idea to hard-code a password into a script that’s stored in Sysvol.
If an account with that name already exists, the script will quit. Some basic events are also logged to the Event Log to indicate what happened.
My first revision of the script used ADSI to create the account and add it to the Administrators group, but I found that my mileage varied with that method. Some computers had the account created, but it wasn’t a member of Administrators.
It’s now set up to use plain “NET USER” and “NET LOCALGROUP” commands. This is an example of what would be executed:
This script is designed to be set up as a computer Startup Script:
Rebuilding your PC is always a drag, even with useful utilities like Ninite.
I recently created a PowerShell DSC script that I can use whenever I need to rebuild my PC. As part of that, I used the cChoco provider to automatically install applications using Chocolatey. I’ll be writing a blog post with more details shortly.
That’s a great way to get the applications installed, but not for keeping them up-to-date. Chocolatey allows you to run ‘choco upgrade all’ manually to do this:
Rather than manually create the scheduled task to automate this, I created this short PowerShell script:
The script will:
- Locate the choco.exe binary (It’ll quit if it can’t find it in the path)
- Set up a scheduled task that runs said binary at system startup
Note that this script will only work on Windows 8 and newer machines, because it relies on the *-ScheduledTask cmdlets.
I’ve been doing a bit of work with DHCP over the last week or so – specifically with troubleshooting IP assignment from various VLANs. I threw together a quick function to read the last (x) lines out of the current day’s DHCP server log. For now, there’s no support for reading the logs remotely. This needs to be run on the server itself.
Once you’ve dot sourced the script, just call the function. By default, it will grab the last 20 lines out of the current day’s log file.
You can specify a day, and/or the number of lines to grab from the end of the log file:
Get-DHCPServerLog -Lines 5 -Day mon
You can also pipe it to Select-Object:
Get-DHCPServerLog | Select-Object Date,Time,Description,MAC*,IP* | Format-Table -AutoSize
Here’s the source:
There are plenty of articles around the Internet discussing how to enable or disable a Wi-Fi adapter based on the status of the wired connection. Whilst I’ve seen that some Dell laptops have this as a simple option in BIOS, our Lenovo machines do not, so this post describes how I achieved a workable solution.
Yesterday I was working with two IT professionals who had probably over 25 years of combined experience working with Windows, but neither of them was aware of this useful technique.
I had to remove a registry value this morning to reverse a change I made last year, and instead of firing up the GUI to do so, I decided I’d make myself a New Year’s resolution on my first day back at work;
If you’re going to do something, try doing it in PowerShell first.