Recently a client called up saying that they are getting the following error message every time they open up Word:
This error is only appearing on one particular user’s computer (not the entire office) and also when they open Word in Safe Mode, it’s non-existent, which is a good sign. When the client is getting this error message, when they try to close down Word, they also receive the following message:
Recently I had a request come through from a client to change a Virtual Machine’s disk from Thin to Thick provisioned.
To achieve this is relatively easy and can be done by following these steps:
1. Log into vSphere and get the location of where the Virtual Machine disk is located
2. Power off the Virtual Machine
3. Browse the Datastore and find the .vmdk file
4. Right-click on the .vmdk file and click Inflate
Recently a client of mine required SSL to be enabled for Apache Tomcat. A 3rd party had installed their software and setup Tomcat, but required it to be configured for SSL This was a rather large pain to get going, but now that it’s working, I feel it would be rather helpful having the full instructions on what to do to get it all up and running.
Basically how it works is that you have to create a KeyStore that will reside on the server that’s running Tomcat. This KeyStore will contain certificates for the server and will be referenced by a server.xml file which controls Tomcat.
Generate the CSR
1. Create a new folder in C: called “Tomcat SSL”. This will house all the certificates and KeyStores associated with this task.
2. From a Command Prompt, navigate to the Java folder and find keytool.exe
Usually located here: C:\Program Files (x86)\Java\jre1.8.0_91\bin
3. Create the new KeyStore by typing in the following command:
keytool.exe -genkey -alias [fqdn of website] -keyalg RSA -keystore “C:\Tomcat SSL\Keystore.jks”
This will then ask you to type in a password. It doesn’t have to be too complex, but make sure it’s something you can remember.
CMD will then prompt you for the following information:
Recently when I was troubleshooting some Exchange issues on a client’s server, I noticed the following Event log and thought I would troubleshoot it further:
What’s happening is that a ‘Foreign Connector’ is still present in the Active Directory and Exchange configuration for an old SBS environment (SBS was recently decommissioned). This is for SharePoint email to web feature, which was never used and it’s not needed.
To get rid of this, it’s safe to just delete the connector. To find the connector, type the following:
Get-ForeignConnector | fl
To delete the connector, type the following:
Remote-ForeignConnector “Windows SBS Company Web Connector SERVERNAME”
This will remove the orphaned connector, clean up the errors and stop them from occurring.
Recently a client of mine noticed that their Exchange server (Exchange 2013) was getting an event log every five minutes saying the following:
There was no interruption to mail flow, but we wanted to look into it and find out why it was happening. I had a look into this event and it looks like there was an issue with this Health Mailbox. Having a look into what the best cause of action is, it was understood that these can be deleted from AD without any issues.
I logged into the DC and deleted the specific user account in question:
Recently I was required to create a Windows 7 VM within a Hyper-V environment (Server 2012 R2). When creating the new Virtual Machine and installing Windows, I noticed that it would hang on ‘Starting Windows’:
There was nothing that could be done which would allow this VM to progress further than ‘Starting Windows’. Upon looking into the setup of the VM, I noticed it had been created as a ‘Generation 2’ machine. Gen 2 Hyper-V machines are only support for Server 2012 or Windows 8 and above. Because this was a Windows 7 VM, it wasn’t supporting and not working.
To resolve this, you need to delete the VM, then go back into the Hyper-V Manager and make sure you select Gen 1 as your preferred VM Generation.
Recently I was on a Domain Controller and accessing the DHCP Server console, and I noticed that the server address was showing a 169 address instead of the server name. DHCP was working fine and there was no issue with the way that it was all working, but it was rather odd that it was showing this address, so I decided to look into it further.
It turns out that the DHCP console was getting it’s IP address from a NIC that wasn’t in use, hence the 169 address. A quick fix here was to disable the NIC itself. After closing and re-opening (refresh would also suffice), DHCP showed the FQDN of the server, and it was back to normal.
Recently a client of mine advised they had a few issues with their GPOs suddenly not applying. After looking through what the issue could be, we added Authenticated Users to the permissions list and gave them ‘read’ permissions. This suddenly resolved the issue.
Authenticated Users didn’t have permission before, as it was locked down by Security Group. I hadn’t made any changes to the GPO and neither had the IT team onsite. This prompted me to look into this further.
Upon investigation, I found that this was caused by a Windows Update (https://support.microsoft.com/en-us/kb/3163622). The update details are the following:
MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the computer’s security context. This issue is applicable for the following KB articles:
All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.
This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.
To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
SQL Log Shipping is a simple solution that operates and provides disaster recovery protection at the database level for SQL instances. The general gist is that the database data/logs are replicated/backed up to a secondary server which is also running SQL and allows the database to failover and start running on the secondary site if there is a problem with the primary site. It’s nice and simple to get going, so if you have multiple sites and can spare the SQL licenses, it’s definitely recommended.
Before starting this setup, you will need to ensure that you have a network location that you can backup your current SQL database to. This can be on the same server that your primary instance, but needs to be shared out and obviously accessible. In terms of a file structure, it would be a good idea to have Instance > Database names. That way it is easy to manage and you know which database goes where.
It is also assumed that you have created a share on the secondary SQL server, where the logs will be shipped to. This will be where your fail over data goes to. The file structure should be the same as the primary server and also shared out.
1. Make sure that your database is in ‘full’ or ‘bulk-logged’ recovery mode.
2. Click on Transaction Log Shipping, then tick Enable this as a primary database in a log shipping configuration
3. Select Backup Settings, and then select the network path location. This will be where you’re database will be backed up to and should be on the same server as your primary server.
Today I was decommissioning an Exchange 2007 server for a customer. The uninstall process got down to “Remove Exchange Files” where it just hanged and did not proceed. The environment was running Exchange 2007 SP2 on Windows Server 2008 Standard SP2.
After a quick search I found that I ran into a known uninstall issue. The hanging in removing the Exchange files is caused by a final Powershell script that won’t run so instead of ending in failure it just hangs and gives the appearance that it is still processing the removal.
All you need to do is open task manager and kill powershell.exe. Doing this will automatically spawn a new Powershell and allow the removal to complete. In my situation, the removal completed within 10 seconds of the new Powershell launching.