Artifact Weblog

GCPW Issue - Your administrator doesn't allow you to login with this account... After installing Google Credential Provider for Windows and then proceeding to login with a Google Workspace account, one can sometimes encounter the following error message at the login screen: "Your administrator doesn't allow you to login with this account. Try a different account" This is often attributed to the Google Workspace admin not having added your domain to the allowed list, however, in my experience, this has never been the issue. It seems that there can be a lag before the PC gets the correct settings sync'd from the Google cloud to the GCPW client.  Manually forcing an update has always resolved things for me, at least so far.  Here is the process: - Open up the Task Scheduler on the Windows PC concerned. - Browse through the Task Scheduler Library, then into GoogleSystem, and finally into GoogleUpdater. - Right-click on the task named "GoogleUpdaterTaskSystem......

I've encountered a few Windows 11 machines lately, some brand new, that haven't had the Print Management Console installed. Trying to run it from the Run menu using "printmanagement.msc" didn't work either. The fix is to run this from a command prompt:  dism /Online /add-Capability /CapabilityName:Print.Management.Console~~~~0.0.1.0

I was encountering an issue at a customer's site where the DNS records of their client PCs often would be behind or out of sync with the records in DHCP.  Usually the IP address would be older in DNS and this was causing issues with scripts executing and network tools correctly resolving client PC hostnames to their correct IP addresses. I realised I needed to make some changes to their dynamic DNS updating configuration.  After a lot of reading through Microsoft's documentation and various online forums, this is what I ended up configuring.  Hopefully this may help someone, some day: - Make the DHCP server a member of the "DnsUpdateProxy" group -  Create a new user account, in the "Users" OU, called "dnsdynamicupdates"   - This new user only needs to be a member of the "Domain Users" group - no special privileges   - Make the password strong and set it to never expire - Set this new user as the credentials used by the DCHP server in IPv4...

This is a pretty infuriating error and can sometimes crop up as a result of running a "wsusutil reset" command. First of all, give the server some time, and then a bit more...  but you've probably already done this. These steps may help to resolve the situation: - Install Microsoft SQL Management Studio (free download) - Run SQL Management Studio and start to connect to the WSUS database - Enter this in the "Server Name" box:  \\.\pipe\MICROSOFT##WID\tsql\query - Expand the "Databases" tree - Right-click on "SUSDB" and choose "New Query" - Paste this query in:     UPDATE tbSingletonData     SET ResetStateMachineNeeded = 0 - You should see a message like "1 row affected", which is good - Quit SQL Management Studio - Open "Services" and restart the "WSUS Service" - Now, open WSUS

Here is the method to convert a Ruckus Unleashed AP to one which can be managed by a Ruckus ZoneDirector controller: - Login to https://support.ruckuswireless.com/ - Click "Downloads" - Choose the correct product, e.g. Ruckus R550 - Choose a "standalone" version along the lines of 118.2.0.0.875.bl7 or something similar - Agree to terms and download the software - Connect to the AP's IP address - It should open the setup wizard, showing "Unleashed Installation" - Click "Local Upgrade" - Choose the firmware image file you just downloaded - It will upload, process, and then be ready for upgrade when you click "Yes" - After this, the ZD should detect the new AP - The new AP will then need to be approved - The new AP will then be upgraded to the correct software by the ZD - The new AP will then reboot and should be ready to use - Don't forget that, for the ZD to even detect, let alone manage the new AP, it must have enough licenses

Problem  Was having difficulty with a logon script I had created and was deploying to users via Group Policy. The script was to customise printer settings for certain users. But it just wasn't running when the users would logon to their PCs. The GPO was applying properly, and I could run the script manually without issue. Cause It turns out that it was happening because, by default, logon scripts don't run for 5 mins after logon occurs on a Windows client PC. Solution This can be adjusted by setting the "Configure Logon Script Delay policy" to "Enabled" and then configuring a better delay. Note: if this policy is set to disabled or not configured, the default delay of 5 mins will apply. I initially set this delay to "0" but found that wasn't successful.  Perhaps the script needed a small delay. So I set it to "1" (1 minute) and it worked nicely. I must also note that during the troubleshooting process, I read many recommendations to e...