To clear cached credentials in TFS 2017 browse to C:\Users\
Wednesday, July 17, 2019
Visual Studio 2017 TFS Client - Clear Cached Creds
This one is just a note for me.
To clear cached credentials in TFS 2017 browse to C:\Users\\AppData\Roaming\Microsoft\VisualStudio\15.0_ed299a44\Team Explorer and delete the TeamExplorer.config file. You will then be prompted for credentials next time you start the TFS client.
To clear cached credentials in TFS 2017 browse to C:\Users\
Saturday, June 15, 2019
Hyper-V SCSI Controller Error
I recently upgraded storage on my Hyper-V server that hosts all of my virtual machines to SSD drives. As part of this, I got lazy for some of the VMs and copied the files manually from drive to drive by using File Explorer rather than moving the VM storage by using Hyper-V Manager. After the disk reconfiguration was done, I got this error for the VMs where I had simply copied the data.
This is a permissions error indicating that the VM doesn't have access to it's own virtual hard disk. As part of my file copying, the VM level permissions were lost. You can see in the screenshot below that only System, Administrators, and Users have permissions. Normally, you should also see permissions for a GUID that represents the VM with Full control.
A quick and dirty fix that you can use for test environments is giving Full control to Everyone. However, for production we can do better than that. We can rebuild the permissions for each VM properly.
The basic process is:
Then set permissions by using icacls.exe:
Notice that in the example that granting permissions is combination of the GUID and the permissions that we want to assign. In this case, the GUID is being assigned full control (F) permission. The result is shown in the permissions.
If you only have one or two VMs to fix, this method is pretty quick and easy. However, I had about twenty of them. So, I created a script to handle this.
This script will ask you for the name of the VM. You can enter a single VM name or a text pattern to query a list of VMs.
Then the script loops through each of the VMs, finds the disks for each VM, and sets the permissions.
If you have snapshots on the VMs, it properly sets the permissions on the .avhd file in use for the snapshot. I have not verified whether permissions on the main .vhdx file that the snapshot is based on need to be modified after a snapshot is removed. Worst case, just run the script again for the VM and it will fix it after the snapshot is removed.
Synthetic SCSI Controller (Instance ID GUID): Failed to Power on with Error 'General access denied error'.
Account does not have permission to open attachment 'PathToVirtualDisk'. Error: 'General access denied error'.
This is a permissions error indicating that the VM doesn't have access to it's own virtual hard disk. As part of my file copying, the VM level permissions were lost. You can see in the screenshot below that only System, Administrators, and Users have permissions. Normally, you should also see permissions for a GUID that represents the VM with Full control.
A quick and dirty fix that you can use for test environments is giving Full control to Everyone. However, for production we can do better than that. We can rebuild the permissions for each VM properly.
The basic process is:
- Get the GUID for the virtual machine
- Set permissions on the virtual hard disk file for the GUID
(Get-VM VMName).VMId.Guid
Then set permissions by using icacls.exe:
icacls.exe VirtualDiskFile /Grant Guid:F
Notice that in the example that granting permissions is combination of the GUID and the permissions that we want to assign. In this case, the GUID is being assigned full control (F) permission. The result is shown in the permissions.
If you only have one or two VMs to fix, this method is pretty quick and easy. However, I had about twenty of them. So, I created a script to handle this.
$VMName = Read-Host "Enter VM Name or name pattern (Example NYC*)" $VM = Get-VM $VMName Foreach ($v in $VM) { $Disks = Get-VMHardDiskDrive $v $Permissions = $v.VMId.Guid + ":F" Foreach ($d in $Disks) { icacls $d.path /grant $Permissions } }
This script will ask you for the name of the VM. You can enter a single VM name or a text pattern to query a list of VMs.
Then the script loops through each of the VMs, finds the disks for each VM, and sets the permissions.
If you have snapshots on the VMs, it properly sets the permissions on the .avhd file in use for the snapshot. I have not verified whether permissions on the main .vhdx file that the snapshot is based on need to be modified after a snapshot is removed. Worst case, just run the script again for the VM and it will fix it after the snapshot is removed.
Thursday, June 13, 2019
Set PowerShell prompt text
I have an annoying issue where I'm storing scripts in a path so long that it makes it awkward to work at the PowerShell prompt. Almost everything I do is wrapping onto the next line.
So, to set the prompt to static text that doesn't include the path, use the following command:
If you do need to view the current directory, you can use Get-Location or $pwd.
So, to set the prompt to static text that doesn't include the path, use the following command:
function prompt {"PS> "}If I'm working with PowerShell prompts connected to different Office 365 tenants, I'll put in text that identifies the tenant.
If you do need to view the current directory, you can use Get-Location or $pwd.
Unable to add drive to storage pool
I bought some new SSD drives for my test server that I run VMs on. The number of disks the system could handle was maxed out. So, I needed to shuffle around some data as part of the installation process.
During my shuffling, I temporarily added two of the SSD drives and used them as normal drives (not in a storage pool). Later, I deleted the data from those drives and wanted to create a new storage pool with those two drives. However, I found that when I ran the wizard to create the new storage pool, the drives were missing (not listed). They were also not listed in the primordial pool.
Using Server Manager, I tried:
After a quick bit of searching, I found that running Reset-PhysicalDisk should change the CanPool property to True. And it did. My surprise is that resetting the drive using Server Manager didn't reset that property to True.
Once I reset the disks with Reset-PhysicalDisk, I was able to create a new storage pool using those disks. And my test server has never been faster!
During my shuffling, I temporarily added two of the SSD drives and used them as normal drives (not in a storage pool). Later, I deleted the data from those drives and wanted to create a new storage pool with those two drives. However, I found that when I ran the wizard to create the new storage pool, the drives were missing (not listed). They were also not listed in the primordial pool.
Using Server Manager, I tried:
- removing volumes
- resetting the drives
- reinitializing the drives
- taking the drives offline and online
- changing between GPT and MBR
After a quick bit of searching, I found that running Reset-PhysicalDisk should change the CanPool property to True. And it did. My surprise is that resetting the drive using Server Manager didn't reset that property to True.
Once I reset the disks with Reset-PhysicalDisk, I was able to create a new storage pool using those disks. And my test server has never been faster!
Tuesday, November 13, 2018
Outlook Encryption Type Error with Office 365
Office 365 allows you to send email via SMTP based on user authentication. This is commonly used in conjunction with POP or IMAP clients. Where POP or IMAP is used for reading messages and SMTP is used to send the messages. This might also be used by applications and multi-function devices that need to send email.
To send SMTP messages through Office 365, you use the following settings:
If you select the wrong encryption type then Outlook will fail to authenticate. For example, if you select the encryption type as SSL/TLS You get the following error which indicates: "Your server does not support the connection encryption type you have specified."
It's pretty rare to run into this error because most of the time, you'll be using autodiscover to configure Outlook and use the web-based protocols. However, you might run into this if you're testing to verify that an account is working properly as part of troubleshooting an app or multi-function device.
To send SMTP messages through Office 365, you use the following settings:
- Server: smtp.office365.com
- User name: UPN of mailbox
- Outgoing SMTP server port: 587
- Encryption type: TLS (STARTTLS in recent versions of Outlook)
If you select the wrong encryption type then Outlook will fail to authenticate. For example, if you select the encryption type as SSL/TLS You get the following error which indicates: "Your server does not support the connection encryption type you have specified."
It's pretty rare to run into this error because most of the time, you'll be using autodiscover to configure Outlook and use the web-based protocols. However, you might run into this if you're testing to verify that an account is working properly as part of troubleshooting an app or multi-function device.
Thursday, October 11, 2018
Querying IP Addresses for EOP using PowerShell
There is always a desire to lock down the communication for Exchange hybrid servers. If you want to lock down a receive connector in your on-premises Exchange for communication with Exchange Online, there is a published list of IP addresses:
The only IP addresses on that web page that are relevant for a receive connector those for Exchange online and TCP port 25. These are the IP address for Exchange Online Protection (EOP).
To simplify automated configuration, Microsoft also makes these IP addresses available in XML format downloadable directly from Microsoft. You can download this using PowerShell.
Once you have that list of IP addresses, it's easy to configure a receive connector with that list of addresses.
The only IP addresses on that web page that are relevant for a receive connector those for Exchange online and TCP port 25. These are the IP address for Exchange Online Protection (EOP).
To simplify automated configuration, Microsoft also makes these IP addresses available in XML format downloadable directly from Microsoft. You can download this using PowerShell.
[xml]$xml = invoke-webrequest -uri https://go.microsoft.com/fwlink/?LinkId=533185Once you have downloaded the xml file, you can extract just the IP addresses for Exchange Online Protection.
$EopIP = (($xml.products.product | Where-Object name -eq "eop").addresslist | Where-Object type -eq "ipv4").address
Once you have that list of IP addresses, it's easy to configure a receive connector with that list of addresses.
Set-ReceiveConnector -Name O365 -RemoteIPRanges $EopIP
Wednesday, September 19, 2018
Unable to Enable MailUser
It's rare, but occasionally I run into a need to edit Exchange attributes on user mailboxes manually. Last week I had a situation where a user account had no Exchange mailbox, but did have some Exchange attributes populated.
This left me in a scenario where running Enable-MailUser failed for the user accounts. For some of the accounts, blanking out the HomeMDB attribute was sufficient. However, for two accounts, even after blanking out HomeMDB it didn't work.
When I ran Get-User (the Exchange cmdlet) it reported back that the account was already a MailUser. However, if I ran Get-MailUser I got an error back indicating that: "The operation couldn't be performed because object 'username' couldn't be found on 'servername'".
The fix for these two user accounts was to blank out the two additional attributes:
Additional reading:
This left me in a scenario where running Enable-MailUser failed for the user accounts. For some of the accounts, blanking out the HomeMDB attribute was sufficient. However, for two accounts, even after blanking out HomeMDB it didn't work.
When I ran Get-User (the Exchange cmdlet) it reported back that the account was already a MailUser. However, if I ran Get-MailUser I got an error back indicating that: "The operation couldn't be performed because object 'username' couldn't be found on 'servername'".
The fix for these two user accounts was to blank out the two additional attributes:
- msExchRecipientDisplayType
- msExchRecipientTypeDetails
Additional reading:
Subscribe to:
Posts (Atom)






