Failed to register Fiddler as the system proxy.

I installed Fiddler on a new Windows 10 workstation.  When starting up Fiddler, I get the following error message: “Failed to register Fiddler as the system proxy.”

When I try to capture traffic (F12) I get the same error message. No
traffic is captured.

Netstat shows Fiddler is listening:

C:\>netstat -an | find "8888"
TCP 127.0.0.1:8888 0.0.0.0:0 LISTENING

After searching high and low, the fix is quite simple.  Just go and start the WinHTTP Web Proxy Auto-Discovery Service.  It was disabled on my workstation.  After that, Fiddler works as expected.

Get the Microsoft SQL version query

SELECT
  CASE 
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '8%' THEN 'SQL2000'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '9%' THEN 'SQL2005'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '10.0%' THEN 'SQL2008'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '10.5%' THEN 'SQL2008 R2'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '11%' THEN 'SQL2012'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '12%' THEN 'SQL2014'
     WHEN CONVERT(VARCHAR(128), SERVERPROPERTY ('productversion')) like '13%' THEN 'SQL2016'     
     ELSE 'unknown'
  END AS MajorVersion,
  SERVERPROPERTY('ProductLevel') AS ProductLevel,
  SERVERPROPERTY('Edition') AS Edition,
  SERVERPROPERTY('ProductVersion') AS ProductVersion

Get-ADUser and Filtering out $null values

Are you having challenges with the Get-ADUser commandlet not pitching errors on a -Filter producing $null results?  Intuitively, it would make sense for the -Filter to filter those out with a -ne $null.  Well, it doesn’t work that way.  There is a Where-Object commandlet that one can pipe to  and filter out those things.  In my example, I chose to filter out $null User Principal Names.  Here’s the example:

$myNonNullUsers = Get-ADUser -Filter { enabled -eq $true } -Properties * | Where-Object {$_.userPrincipalName -ne $null}

Automatically Assign Licences to New Office 365 Accounts

Here’s the scenario: Users are created in Active Directory, on-premise.  The AD Sync Service then will sync up the user account to Office 365.  However, a license is not assigned.  The rule of thumb when assigning new licenses is that people in the call center get an E1 license and the rest of the employees get an E3 license.  The identifying characteristic for the call center users is that their email address is <someone>@mycallcenter.com and everyone else has a different domain for their email.  For your use case, you may have other specific identifiers to help determine the appropriate license.  If one size fits all, you can eliminate the the lines to change to an E1 license and leave the default.

I chose to use a security group to identify users that need a license assigned.  In this case it’s “ADGroup-UsersNeedingLicenses”  When the script runs it will iterate through all members of that security group  and check to see if the account has synchronized up with Office 365.  If the account is there, it will evaluate which license to assign and then assign it.  It will then get the user’s licenses from Office 365 and display them so you can validate that it was updated.  It then removes the user from the security group and we’re done.

If you like, you can set this on a scheduled task to automatically assign licenses to new users on an interval.  One would need to store credentials in a file in order for it to be automated.  I like it because it’s one less administrative task I need to deal with.  I can create the account in AD then go take care of other things.  I come back after a bit and then the user is synchronized and licensed.

<# Get credentials to connect to Office 365 using PowerShell#>
$Password = Get-Content j:\myscripts\ADCredentials.txt | ConvertTo-SecureString
$credential = New-Object System.Management.Automation.PsCredential("ServiceAccount@company.onmicrosoft.com",$password)

<# Connect to MSOL #>
Connect-MsolService -Credential $credential

<# Get AD Users designated for license assignment #>
$usersNeedingLicense = Get-ADGroupMember -Identity ADGroup-UsersNeedingLicenses

<# Iterate through the collection of AD users designated for license assignment #>
ForEach ($ADUser in $usersNeedingLicense){
 $ADUser = Get-ADUser -Identity $ADUser -Properties *
 "AD UPN: " + $ADUser.UserPrincipalName
 
 Try {
 $o365User = Get-MsolUser -UserPrincipalName $ADUser.UserPrincipalName -ErrorAction Stop
 $licenseType = "mycompany:ENTERPRISEPACK" <# set default to E3 #>
 If ( $ADUser.UserPrincipalName.Contains("@mycallcenter.com")){$licenseType="mycompany:STANDARDPACK"} <# Assign E1 #>

 "Assign: $licenseType"
 <# Locate and assign license using matching UPN #>
 Set-MsolUser -UserPrincipalName $ADUser.UserPrincipalName -UsageLocation "US" <# Set user licensing to Unites States #>
 Set-MsolUserLicense -UserPrincipalName $ADUser.UserPrincipalName -AddLicenses $licenseType
 <# view for validation #>
 Get-MsolUser -UserPrincipalName $ADUser.UserPrincipalName | fl UserPrincipalName, Licenses
 <# Remove AD user from ADGroup-UsersNeedingLicenses #>
 Remove-ADGroupMember -Identity ADGroup-UsersNeedingLicenses -Members $ADUser.SamAccountName -Confirm:$false
 }

 Catch [System.Exception]{
 $ADUser.UserPrincipalName + " is not in Office 365 yet."
 $error
 }
 Finally {$error.Clear() }
}

Use SCP to copy files from Linux using PowerShell

There’s a lot of different tools out there to essentially SSH to a Linux host.  They seem to come short when one needs to use secure copy.  WinSCP has been around forever and is a relatively mature tool for doing SCP on a Windows client.  My requirement is to copy files from a Linux server to a Windows client.  WinSCP seems to be the best fit for my one need.  Here are the general steps to getting it done:

  • First install WinSCP wrapper to enable use of SCP from PowerShell.  Windows Management Framework 5.0 is a prerequisite.
  • Run the WinSCP application to collect the key from the target Linux host.
  • Generate credentials to be used by a script to copy files.  Run a script to copy the files.
  • If needed, set up a scheduled task to run the copy script on an interval.

Download WinSCP .NET assembly for use with PowerShell: https://winscp.net/eng/docs/library_powershell#powershell_scripting

In PowerShell running as administrator, run the following:

Install-Module -Name WinSCP

Check the install by running the following:

Get-Command -Module WinSCP

Store credentials to be used in a later script.
Save Password to File
$credential = Get-Credential
$credential.Password | ConvertFrom-SecureString | Set-Content G:\scripts\PasswordFile.txt

Run a script the uses the password file to access the Linux server and copy over your files.
$session = New-WinSCPSession -Hostname <Linux Host> -Credential $credential -SshHostKeyFingerprint "ssh-rsa-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx"

Receive-WinSCPItem -WinSCPSession $session -Path “/…/somefile” -Destination “C:\folder\destination\etc\”

Remove-WinSCPSession -WinSCPSession $session

Office 365 – Shared Mailbox – Sent email not saving in shared “Sent Items”

Shared mailboxes migrated just fine into Office 365 (Exchange Online) shared mailboxes.  Users that are able to send email on behalf of the shared mailbox are having the sent email copy stored in the “Sent Items” of the sender as opposed to the “Sent Items” of the shared mailbox.  All the people who share use of the shared mailbox would like to be able to see sent email by others using the  shared mailbox.

Microsoft decided that this should be an ability of Exchange Online, but did not set that behavior by default. Please refer to this TechNet article for more details on how to set this behavior.

I needed a script that would be able to march through all the shared mailboxes and make the change.  Here’s the script:

$sharedMailboxCollection = Get-Mailbox -Filter {RecipientTypeDetails -eq 'SharedMailbox'}
foreach ($mailBox in $sharedMailboxCollection)
 {
 $mailBox.UserPrincipalName
 set-mailbox $mailBox.UserPrincipalName -MessageCopyForSentAsEnabled $True
 set-mailbox $mailBox.UserPrincipalName -MessageCopyForSendOnBehalfEnabled $True
 }

Setting permissions on home drive folders

Scenario: Home drives were initially shared out on a Linux based NAS appliance.  The device fails, but the data remains intact. The data is recovered using a file copy utility.  The data is recovered… Yay!  All the NTFS-like file permissions are gone… 🙁

By the way, here’s a really good blog that details the required NTFS permissions for user home drives:

Automatic creation of user folders for home, roaming profile and redirected folders.

I get to fix these sorts of things!  Welcome to my world!

Now, I need to iterate through all of the folders and set them for each individual user.  Doing through the NTFS permissions GUI for each one is a Systems Administrator’s purgatory.  Needless to say, I’m not going to do that.  Wouldn’t it be better to script that?  I see a bunch of virtual heads nodding and I agree.

I’m going to do it using PowerShell module that was created by Raimund Andree.  Thank God for that cat!  You can get the module here: https://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85

More details on how to use the module to manage NTFS permissions can be found here: https://blogs.technet.microsoft.com/heyscriptingguy/2014/11/22/weekend-scripter-use-powershell-to-get-add-and-remove-ntfs-permissions/

$userFolderPath = "E:\User\"
$folders = Get-ChildItem $userFolderPath
foreach ($folder in $folders)
{
    $ADUser = Get-ADUser -Filter {Enabled -eq  $true -and SamAccountName -eq $folder.Name} -Properties CanonicalName
    if (-Not ($ADUser -eq $null))
    {
        $domain = $ADUser.CanonicalName.Substring(0,$ADUser.CanonicalName.IndexOf("."))
        $userSecurityPrincipal = $domain + "\" + $ADUser.SamAccountName
        $userFolder = $userFolderPath + $folder
        $userSecurityPrincipal + " => " + $userFolder
        Add-NTFSAccess -Path $userFolder -Account $userSecurityPrincipal -AccessRights FullControl
    }
}

Creating home drive folders for users without one

Of course I know that one can use the “Home folder” option in the Profile of the user in Active Directory.  Due to certain constraints of a situation I inherited, that’s really not an option for now.

I need to do it in bulk, for a bunch of active user accounts within a specific OU.  Additionally, I don’t know if the user has a folder or not.  Nor do I feel like waiting for these users to login and then have the folder created.

Luckily for me, I have a ton of storage and a single location for user home folders.  I simply want to walk through all the users in a specific OU, like “…this\path\to\my\ou\…”  If the folder does not exist, then go ahead and create it.

$homePath = "Q:\UserHome\"
$userHome = get-aduser -filter {enabled -eq $true} -properties SamAccountName,CanonicalName
foreach ($ADUser in $userHome)
{
  if ($ADUser.CanonicalName -like '*/myOu/Path/*')
  {
    $userHomePath = $homePath + $ADUser.SamAccountName
    if (-Not (Test-Path $userHomePath))
    {
      New-Item $userHomePath -Type Directory
    }
  }
}

Remove home drive folders for inactivated users

I ran into an challenge where there were tons of home folders for users that may or may not be active.  The folders were named according to the User ID used to login to user workstations.  In Active Directory, this was known as SamAccountName.

Going through Active Directory to find each user’s SamAccountName and then see if there’s a corresponding home drive folder would be tedious at best.  So, there must be a better way!

Here’s a script that will iterate through all the user folders in the “E:\User” folder and then remove deactivated user folders to the “E:\DeletedHomeDirectories” folder to be dealt with later.

<# RemoveFoldersWithoutUsers.ps1
By Frank Contreras
Use at your own risk
#>
$folders = Get-ChildItem "G:\UserShare\"
foreach ($folder in $folders) 
{
  $ADUser = Get-ADUser -Filter {Enabled -eq $true -and SamAccountName -eq $folder.Name}
  if ($ADUser -eq $null)
  {
    "Removing " + $folder
    $source = "G:\UserShare\"+$folder
    $destination = "E:\DeletedHomeDirectories\" + $folder.Name
    Move-Item -Path $source -Destination $destination
  }
}

Career and Professional Website