I ran into an issue today that I was banging my head against until I found an obscure Vmware article.
Basically, when I tried to access my VDP appliance through the browser via port 8545, Chrome and IE would both say the connection was dropped or not accessible. “Failed to load” or “is not available” were the other errors.
This is the article I found:
When Chrome/Firefox changed some settings regarding SSL certificates, it basically broke being able to access VDP devices that hadn’t been updated in a while. The above article has a Hotfix that you can install to fix the issue. It did for me!
My cpanel has finally been updated to include integration with Let’s Encrypt. The process took 10 seconds and I have a glorious auto-renewing SSL certificate.
Quick and easy tip today. A user left the company and to free up the license used on Office365 but keep the user’s mailbox, you can easily convert the mailbox to a shared mailbox, which you don’t get charged for on Office365.
Basically, go into Exchange Admin Center > Recipients > Choose the Mailbox you want to convert and on the right side, click “Convert to Shared Mailbox”
To disable Clutter in Office365 via Powershell, simply do the following:
Connect to Office365 Powershell for your account
Then simply run this command to disable Clutter for all mailboxes:
Get-Mailbox | Set-Clutter –enable $false
That’s it! If you want to disable Clutter for a single mailbox, you can do the following:
Set-clutter -identity [email protected]-Enable $false
To do this via the Office365 Portal, just navigate to: Mail > Automatic Processing > Clutter and turn it off!
While trying to install Java today, I encountered an error that wouldn’t go away: Error 1603. Scouring Technet forums, blogs, etc. no one had a real sense of what the cause was. Some said it was an old Windows Update. Some said it was a bad Java installer package.
Eventually I found my solution: I was connecting through LogMeIn to the device. I ended the LogMeIn task and process, RDPed in, installed Java… and voila! It worked. Re-enabled LogMeIn and I was on my way.
I had some poor performance with XRDP, so I found this nugget of info that helped things a little:
Backup xrdp.ini (XRDP config)
sudo cp /etc/xrdp/xrdp.ini /etc/xrdp/xrdp.back
Open the XRDP config with nano:
sudo nano /etc/xrdp/xrdp.ini
Under [Globals] change max_bpp to 128 and add this line below:
Restart XRDP services:
systemctl restart xrdp.service
I’ve been playing with Centos recently and have been working on integrated it with a Windows Domain / VM I have setup. To ease accessing it, I found that it is possible setup XRDP (an open-source version of RDP) so that you can access Centos from a Windows system using regular RDP.
Assuming you already have your desktop environment setup, open up terminal and run the following as root:
yum -y install xrdp tigervnc-server
Then, start the service:
systemctl start xrdp.service
To see if it is running, type:
netstat -antup | grep xrdp
I had to run these commands to get it to work:
chcon -t bin_t /usr/sbin/xrdp
chcon -t bin_t /usr/sbin/xrdp-sesman
Followed by restarting the service:
systemctl restart xrdp.service
Then all you have to do is enable the service:
systemctl enable xrdp.service
And put in a firewall exclusion and reload the firewall:
firewall-cmd --permanent --zone=public --add-port=3389/tcp
For more info, this TechNet article was super helpful.
Simple one here – a VIP relies on a Gmail account when the company is on Office365. To allow the VIP to send to a distribution list, I had to do the following:
1) Open Exchange Admin Center
2) Click on Recipients and then Groups
3) Select the distribution group
4) Click the edit button
5) Click Delivery Management and select “Senders inside and outside of my organization”
6) Then just click Save!
You can also use this area to block or allow certain senders to distribution lists by adding emails to the box below.
One of my servers has been getting numerous events logged saying “The Windows Filtering Platform has blocked a packet” with internal IP addresses usually listed.
I found that running these two commands quieted the logging:
auditpol /set /subcategory:”Filtering Platform Packet Drop” /success:disable /failure:disable
auditpol /set /subcategory:”Filtering Platform Connection” /success:disable /failure:disable
If you need any other commands, you can check out the full Microsoft article here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb736284(v=vs.85).aspx
After a round of Windows Updates, I encountered the same error on two different servers at different clients. Both used BackupAssist that relied on Windows Server Backup. They both backed up to NAS’s but one NAS was connected as an iSCSI device and the other was mapped as a network share. The versions of BackupAssist were different, as well. One server was bare-metal, one was an ESXI VM. One was 2012 R1, one was 2012R2.
Among the things I tried were:
- Changing the time of the backup
- Resetting shadow copies
- Changing maximum size for shadow copies
- Changing the VSS mode
- Checking the status of VSS writers
- Restarting the servers
- Restarting backup devices
Eventually I found the backup code, 0x807800C5, on both servers. Googling yielded nothing but a number of other people with the same error running everything from Windows 7 to Windows 2012. After a lot of troubleshooting, I ended up renaming the backup destination that Windows Server Backup used, which gave the backup a clean slate of sorts. Both backups have succeeded since then.
The full error I received was:
(There was a failure in preparing the backup image of one of the volumes in the backup set.). Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.