Monday, November 09, 2020

Disk Management and Explorer Show Different Drive Size

 I ran into this issue today when trying to extend out the drive size on a data drive on our primary file server.  After expanding the virtual disk in VMware, I brought up computer management (compmgmt.exe if you want to go command line quicker).

I expanded out the disk and immediately noticed that explorer didn't reflect that change after a refresh.  Also, disk management could no longer access the disk to make any edits.  I restarted the virtual disk service with no success.  A restart also proved futile.

MAKE A BACKUP BEFORE RUNNING THESE COMMANDS!

After some quick research, here is the fix.  Use DISKPART from an elevated command prompt.  Just follow the commands below and choose the proper disk on your VM.  After running the command, a quick refresh of explorer now shows the correct size.

Good luck!




Tuesday, October 13, 2020

vCenter 6.7 Resizing Disk Fails Invalid Operation for Device 0

 This one has been around for some time but now due to the data drive on my Exchange server getting closer and closer to full, I had to find a fix and here it is.  So simple and yet so hard to find on the web.

Checking the D: drive on the Exchange server showed the disk had a size of 150.254450347GB.  This disk had been restored from Datto at some point in the past and since that date this was the size showing.

Whenever attempting to expand the drive vCenter thew this error:  Invalid operation for device '0'.

I tried different sizes from adding just a few gigs to going all the way up to 200GB but getting the same error.

Ready for the fix?  You won't believe how easy it was.

1. Log into vCenter using the flex (Flash) client instead of the HTML 5 client.

2. Resize your disk successfully.


THAT'S IT!!  Can you believe it?  After all of these articles I read about changing the parameters on the VMX file, cloning the server, etc. etc. it turned out to be the behavior of the HTML 5 client.  Let's hope VMware fixes this in the next versions of vCenter before they fully remove the Flash functionality.

Good luck!

Tuesday, September 08, 2020

Fix Cisco ASDM Windows 10 Error "This app can't run on your PC"

 Seems that Microsoft has done some switching of how the Windows Scripting Host path is found.

This is a simple fix.

1. Install ASDM as you normally would

2. Right click on the shortcut.

3. In the "Target" line you will see a very long path to wscript.exe.  Simply change this path to C:\Windows\System32\wscript.exe (leave the invisible.vbs run.bat on the end as these scripts are used to open ASDM).

4. Apply the change.

After doing this I was able to open ASDM normally and use it to update ASDM and AnyConnect files on my ASA.

Good luck!

Tuesday, June 09, 2020

Exchange Logging: Clear out the log files

Here is a simple PowerShell script that you can run against Exchange either manually as part of your maintenance routine or with Task Scheduler to clear out files when you need to.

I must admit the first time I ran this on my Exchange 2013 server it took almost 5 minutes to complete and freed up over 30G of drive space from the multiple years of log files hidden all over.

At the top of the script make sure you change the drive letter if needed to match where your Exchange log files are stored.  Sadly I have seen many Exchange servers over the years with everything installed on C: so this script just assumes that.

NOTE:  Please make sure you have good backups in place and/or a snapshot of your virtual machine before running this.  While I have tested the script with no negative effects, please do not assume this will always be the case.  There is no substitution for good backups and a quick recovery plan if needed.

If you want to run the file manually, just open PowerShell as administrator, navigate to where you have your script file saved (Example Name:  ClearFiles.ps1).  From there just type in ./ClearFiles.ps1 and wait on the script to complete the cleanup.

Good luck.

Set-Executionpolicy RemoteSigned
$days=2
$IISLogPath="C:\inetpub\logs\LogFiles\"
$ExchangeLoggingPath="C:\Program Files\Microsoft\Exchange Server\V15\Logging\"
$ETLLoggingPath="C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces\"
$ETLLoggingPath2="C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs"
Function CleanLogfiles($TargetFolder)
{
    if (Test-Path $TargetFolder) {
        $Now = Get-Date
        $LastWrite = $Now.AddDays(-$days)
        $Files = Get-ChildItem $TargetFolder -Include *.log,*.blg, *.etl, *.txt -Recurse | Where {$_.LastWriteTime -le "$LastWrite"}
        foreach ($File in $Files)
            {Write-Host "Deleting file $File" -ForegroundColor "white"; Remove-Item $File -ErrorAction SilentlyContinue | out-null}
       }
Else {
    Write-Host "The folder $TargetFolder doesn't exist! Check the folder path!" -ForegroundColor "white"
    }
}
CleanLogfiles($IISLogPath)
CleanLogfiles($ExchangeLoggingPath)
CleanLogfiles($ETLLoggingPath)
CleanLogfiles($ETLLoggingPath2)

Friday, January 17, 2020

Disable User Editing Connections HP ThinPro 7.x (T530)

So I ran into this one yesterday.  After pushing out a configuration to our new HP T530 thin clients I was shocked to discover that one of the users had the ability with the OS locked down to delete their RDP connection icon.

I quickly recreated it on the thin client so they could log back in.  Today I set out to change the configuration and push it to all of our thin clients to prevent this from happening again.  Here's how:

1.  Go into Administrator mode on ThinPro
2.  Right click on the respective connection on the desktop.  Ex: RDP
3.  Select Edit and then go to Advanced.
4.  Remove the check box beside "Allow the user to edit this connection".

This process is the same for all connection types on the thin client.  I read through the Administrator guide and wasn't able to find a global setting so you'll need to do this for each connection type you are using.

I hope this helps prevent you running into the same issue.

Good luck!

I'm Back!

It's been quite a while since my last post as I had transitioned into a job where I was doing more sales and quoting than field work so I didn't really have anything to post.

Now, I have changed jobs and on a daily basis I'm back into engineering and field work again.

To that end, I'm sure I will run into new issues and processes that I'll put up here for everyone to see and use.  I just hope the bits I add helps someone in IT like me get through a tough problem or issue and look like a champ doing it.

Thanks to everyone that has messaged me with questions and support these past few years.  This blog just serves as my small way of helping all of the people that have posted articles and on forums over the years that helped me out of a tight spot.

I hope 2020 and beyond are great for all.

Thanks!