We recently had an issue at work where someone discovered that their calendar could be viewed by another user in the organization that they didnt give explicit permission to. Upon further inspection of the problem, we discovered it was being caused by the exchange role of Reviewer1 being given to the Default user on the user’s calendar folder. The Default user in exchange refers to any user in the organization, so any permissions assigned to it is essentially saying “I want every user in my company to be able to do this to this resource“2. We fixed the user’s issue quickly by modifying the permissions, but I started wondering if anyone else had accidentally modified the Default user on their calendar as well. Powershell time! I created a script to check the Default user permissions on each user’s Calendar folder and return any calendars where it wasn’t set to the company default of AvailabilityOnly.
It takes a while to traverse through all the users, but the script will output it’s progress as it plods along using the Write-Progress cmdlet. I haven’t tested it, but the script should also be able to work on newer versions of Exchange Server as well (just remove the part where it connects to Office365, right above the line $StandardPermission = "AvailabilityOnly"). If you’re interested in more information about calendar permissions in Office365, check out the following article from Microsoft: https://support.microsoft.com/en-us/help/2865291/how-to-set-free-busy-permissions-in-exchange-management-shell-in-offic
Most companies set the default for Default on calendars to something like AvailabilityOnly or LimitedDetails, which lets users view free and busy time in other users calendars to help in scheduling meetings, but nothing else.
I recently ran into an issue at work where someone had set static IPs on a handful of nodes as a temporary fix, but then forgot to exclude the IPs on our DHCP server. This was in turn causing issues with some other nodes that were getting their IPs from the DHCP server dynamically, and were then receiving a DHCP NAK on startup when their assigned address was already in use. With the problem identified, I decided to hunt down these misconfigurations by determining which IPs on our DHCP server should not be in use, and then simply ping them. Determing the IPs that shouldn’t be in use is bit complicated though, as you have to take the IP range you want to query and then remove all leases, reservations, and manual exclusions from it. Thankfully Microsoft provides a powershell cmdlet that does all that work for us, Get-DhcpServerv4FreeIPAddress (phew!). With that cmdlet at hand, we can now take those IPs1 and pipe them out to Test-Connection. Any results that are returned are IPs that the DHCP server believes to be free, but are actually in use as an undocumented static IP.
By default the script will query all scopes, but if you want to get more granular and only target one scope, in the Get-DhcpServerv4Scope command add on the -ScopeID parameter followed by the ID of the scope you want to target.
If you have alot of IPs that you want to query, or just want to monitor the script’s progress, I have a fancier version of this script too.
Get-DhcpServerv4FreeIPAddress can only return a maximum of 1024 addresses per scope. If any scope on your DHCP server has more than 1024 possible addresses in it, be aware that this script may not be able to test them all.
I’ve been working with Ansible of late, and just like Python it’s very finicky about indentation. When modifying Ansible playbooks in Vim I found the need to be able to indent blocks of code all at once. Vim to the rescue! Normally to indent1 one line in Vim you would put the cursor anywhere on the line that you’d like to indent and hit > (with < used to unindent). Now to indent multiple lines we can leverage Vim’s visual mode to select more than one line. Put the cursor on the first line you would like to indent and then type v to enter into visual mode. From here move the cursor down to the last line you would like to indent and press >.
Want to indent the same block of code twice? You may have noticed by now that once you send your indent command you’re then exited out of visual mode, meaning you’ll have to select which text you want to indent all over again. After you’ve used visual mode once, type gv and you you’ll re-enter it with your previous selection already highlighted!
Indenting is set to 8 spaces by default, but this can be changed by modifying the shiftwidth setting in Vim. It can be changed on the fly to 4 by running :set sw=4 in Vim, or permanently by adding the line set shiftwidth=4 into your .vimrc file in your home folder.
At work I sometimes have to set account restrictions up on an account to limit the user to only be able to logon to certain PC’s. Usually this is to restrict the account to only being able to logon to certain computer labs. In the past I would accomplish this by opening up ADUC, clicking on the accounts LogonWorkstation dialog box, and then manually entering each computer that the account needs to logon to, often with the computernames being almost identical(the computers were named after the room number they were located in). I got a bit tired of doing this after a few times, so I started to look into setting the field via PowerShell. The Set-ADUser command lets you set the field by using the -LogonWorkstations parameter, but you have to provide a comma separated list with each host you want the account to be able to logon to. I wanted wildcard support! So to fix the problem, I created a PowerShell module that gave me the wildcard support, Set-ADUserLogonTo. In it are two functions, Get-ADUserLogonTo and Set-ADUserLogonTo. Get-ADUserLogonTo can be used to either return which computers the account is restricted to logging into, or just how many computers are in that list. Set-ADUserLogonTo can be used to either set the restrictions on what the account can log into(click here to get some examples as to how the wildcard support works), or just to remove the restrictions, allowing the account to logon anywhere. If you’d like to install it, check out the project’s README on it’s project page here.
I’ve added a new function to my MDTApplicationTools PowerShell module, called Rename-MDTApplication. The function renames MDT applications, with an optional parameter to rename the applications source directory as well.
Renaming an application via MDT’s GUI usually is pretty easy, so why the function? While renaming an application in MDT works OK, it was missing a bit of functionality that I wanted, which was to also rename the application’s source directory. Via the GUI if I were to rename APP1 to APP2,the name would change to APP2 in MDT, but the source and workingdirectory would still point to .\Applications\APP1. Now with this function, I can safely go back and rename my applications, knowing that my source directories will match their application names.
If you’d like to install the module, head over to MDTApplicationTools project page and checkout the README. If you already have the module installed (and are also running PowerShell 5), just run Update-Module -Name MDTApplicationTools to get the latest version.
Earlier in the year I took charge of my work’s Windows 7 to Windows 10 Migration. I work at a college, and a good part of the machines we manage are computer labs, for which we have to manage about 130 different software packages (I should probably mention at this point that we use the Microsoft Deployment Toolkit to manage all of our images, drivers, and packages). As part of the migration, I wanted to mark all packages in the labs as supporting Windows 7 Only in MDT, and then gradually bring in each package, testing to make sure their installation, settings configuration, and user experience didn’t break in Windows 10, and afterwards removing the OS restriction once I had verified the app was OK. I also wanted a way to query a package that is dependency of a bunch of other packages, so I could then test all those dependent applications to make sure my updating their shared dependency didn’t in turn break those packages themselves(I had one package in mind here for the shared dependency issue. It’s name rhymes with lava)
Through having the Microsoft Deployment Toolkit installed on my computer I had access to all the MDT PowerShell Cmdlets, and could mount my MDT shares as a drive in PowerShell (cool stuff), but I didn’t really have the fine grain control I wanted in order query and manipulate the MDT applications in this manner. So what would be the shortest, easiest, most efficient way to get around these problems? Spend hours upon hours creating a PowerShell module of course! Here’s an excerpt from the README file to give you an idea of what it does:
Retrieves MDT applications, either by name/guid, or just all of them.
Retrieves either the parent or child dependencies of an MDT application. Can either return one depth, or can recurse the entire depth of the dependency tree
Queries MDT applications to see if they have the SupportedPlatform attribute set.
Sets the SupportedPlatform attribute on MDT applications
Searches through either the installcmd attribute or the install scripts themselves of all the MDT applications in a share for the specified string(i.e “pause”, “powershell.exe”, “C:\Program Files (x86)”, etc.)
It took me a while to make, but I learned a ton in the process, and in the end I have a tool that helps me out a great deal when updating or changing applications. If you’d like to learn more, check out the project’s page below. The README file on that page should have all the info you need to get it up and running on your computer.
We recently ran into an issue at my work when using Microsoft Remote Assistance. We’d be able to remote into a user’s PC using Remote Assistance just fine, but then when we ran something that needed admin rights, We’d go from a normal screen to this:
Well that’s not good. The user would be presented with a normal UAC dialog box with a prompt to put credentials in, but the tech helping them just saw a big black box. This was happening because UAC prompts don’t quite go to the user’s desktop, but rather to something called Secure Desktop. To quote Microsoft:
The Secure Desktop’s primary difference from the User Desktop is that only trusted processes running as SYSTEM are allowed to run here (i.e. nothing running as the User’s privilege level) and the path to get to the Secure Desktop from the User Desktop must also be trusted through the entire chain.”
What this means for those using Remote Assistance to help out a user, is that the UAC prompts can be viewed and interacted with on the user’s console, but not via the Remote Assistance session.
The way to “fix” this issue would be to simply disable Secure Desktop, which would keep UAC on, but now present the UAC dialog box on the user’s desktop (and also on the Remote Assistance session). After reading more about Secure Desktop though I decided the need was too small to justify disabling it, as it significantly weakens UAC’s protections, and most especially since we were able to workaround this issue by simply RDPing in as an administrator. With that warning in mind, here’s how to disable Secure Desktop if you decide that’s what’s needed in your environment:
In Group Policy, go to “Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options”, and from there go to the policy “User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop”. From there check off “define this policy setting”, and make sure “enabled” is selected.