In a previous Post I mentioned an issue that I had with a Certificate template on my Internal Enterprise CA not showing up when I tried to request a certificate.
Over the last week I have been working on a certificate issue with Lync 2013. This has effected mobile clients and remote Windows and Apple machines. After Checking the event log on my Lync Front End Server I discovered that I was getting event log errors like this:
And as you can tell from the next picture they were showing up pretty regularly.
So I started googling and I found a few articles online and discovered that this is a known issue that MS Support is aware of but has not permanent fix. They are only offering workarounds at this time. The first one that I found said that the problem is caused by .NET Framework 4.6 and 4.6.1 being installed at the same time and required adding a registry key of the Front End Server which looked like this:
This actually made things worse as it doubled the amount of errors I was getting in the event log.
So I moved on to this lovely technet article I found which worked for me and after reading it I discovered why the first method did not work.
You see because I did not install Lync in the standard location (meaning the C: Drive) the registry key fix would not work. I actually ended up having to regenerate my internal certificates and modify my CA to issue a new certificate template which merges the Webserver Client and Server template.
I am not going to go into further detail on this as the above URL fixed my issue and has very good step by step instructions. I will however probably do a follow post on what happened when I tried to issue a certificate with that template the first time and what I had to do to fix that issue.
While working in my lab at work I wanted to see about adding my vSphere Management Assistant (vMA) to our lab Active Directory so it would be easier for me to connect to resources. After going through the process I decided to make a guide on the steps I took to get it working.
Just an FYI I was working with vSphere Management Assistant version 18.104.22.168 at the time of taking these screenshots so I am sure things may have changed in later versions… or not.
First you will need to get to the console of the machine.
Select the option to login
and log in using the vi-admin account
Once you are logged in you are presented with a command prompt. You will need to use the following command to add your appliance to a Windows domain.
Sudo domainjoin-cli join <domain.name> <Domain User Name>
You will then be prompted for the vi-admin password
Once your Appliance is added to the domain you will see a screen like this.
So one of the projects that I have been working on lately is to setup a Mobile Device Management (MDM) solution for my company. One of the requirement to get email to Sync for the mobile devices was to connect the MDM server to our internal Exchange 2016 server using PowerShell.
One of the issues that I had been running into for a few days was that the MDM was not able to authenticate to our Exchange Server. I went through everything I could think of to fix this issue and to get it working (Check Firewall ports, SSL Certificates, User Permissions) but nothing was working. Then I remembered back to an post I did on here before about Active Sync and how I had to use a PowerShell command to recreate the Virtual Directory with the correct URL at the time of creation otherwise it will cause PowerShell to fail when you try to connect to it externally.
Well the funny thing about this whole situation is that during my troubleshooting I had to remove the PowerShell virtual directory in order to recreate it. Well… It turns out when you remove the PowerShell directory it also disconnects your PowerShell session to the Exchange server. Now fortunately I have a second Exchange server on the same Domain so I was able to run the command to create a new PowerShell Virtual Directory on that server and after turning off the Require SSL check box I was able to connect to the server again. Also my connection to the MDM Server was working as well!!!
Here is the command s that I should have used to create the PowerShell Virtual Directory.
To Remove the PowerShell Virtual Directory:
Remove-PowerShellVirtualDirectory “Powershell (Default Web Site)”
To Create the New Virtual Directory:
New-PowerShellVirtualDirectory -Name Powershell -RequireSSL:$False
To Reset IIS
I have been away for a while, but in my absence I have been playing with a Home Automation System called Home Assistant. You can find out more about it here on their website: https://home-assistant.io/
One of my Father’s Day Gifts from my Wife and Kids was a SmarThing Hub with a Arrival sensor. Now Home Assistant has literally hundreds of pre-built integrations however SmartThings is not one of them. To make it work with Home Assistant you will have to use a protocol called MQTT which is very versatile and can be used to create your own Automations. (Find out more about it here.)
Now my Home Assistant instance is running on a Rasberry Pi 3 (also a Father’s Day Gift) however it also runs on a Raspberry Pi 2. I am also running HASSbain which is a Raspian image created by Home Assistant. As for MQTT there are a few products out there that you can use, I prefer Mosquitto as there seems to be more guides out there on how to configure and manage it.
Start off by checking for and installing updates for Raspian:
sudo apt-get update
sudo apt-get upgrade
this could take a while depending on your setup.
Next you will need to setup the smarthings-mqtt-bridge via npm
sudo apt-get install npm
sudo npm install -g smartthings-mqtt-bridge
Then you will need to setup pm2 to run the processes
sudo npm install pm2 -g
Once installed you will need to create and edit smartthings-mqtt-bridge config
sudo cp /usr/local/lib/node_modules/smartthings-mqtt-bridge/_config.yml ~/config.yml
sudo nano ~/config.yml
Here is what the mqtt-bridge-configuration ~/config.yml file should look like if all is configured correctly.
# Specify your MQTT Broker’s hostname or IP address here
# Preface for the topics $PREFACE/$DEVICE_NAME/$PROPERTY
# Suffix for the state topics $PREFACE/$DEVICE_NAME/$PROPERTY/$STATE_SUFFIX
# state_suffix: state
# Suffix for the command topics $PREFACE/$DEVICE_NAME/$PROPERTY/$COMMAND_SUFFIX
# command_suffix: cmd
# Other optional settings from https://www.npmjs.com/package/mqtt#mqttclientstreambuilder-options
# Port number to listen on
Now that all of the local configurations have been completed you need to configure the SmartThings Device handler, Device, and SmartApp using steps outlined in https://github.com/stjohnjohnson/smartthings-mqtt-bridge150
IP: raspberry pi IP
MAC: Raspberry pi MAC
Next you will need to add mqtt to HomeAssistant config configuration.yaml
Now you will need to add your devices to their own file, or configuration.yaml
Since I am using mine for presence detection mine looks something like this
– platform: mqtt
name: “MQTT Presense Detection”
Friendly Name: smartthings/device name/presence
Friendly Name1: smartthings/device name/presence
Now you will need to start the bridge
sudo ln -s “$(which nodejs)” /usr/local/bin/node
pm2 restart smartthings-mqtt-bridge
restart Home Assistant
sudo systemctl restart home-assistant.service
That should do it. You may want to sudo reboot
In the future I may do more of these as I have learned at lot from it, including beginning to dabble with Docker.
One of my users came to me with an issue regarding his Outlook for Mac Client. He said he was able to see a persons calendar but when he opened them up they were blank.
Most of our users are using Outlook 2013 on either Windows 7/8/10 and are not having this issue. After about an hour of searching online and digging through message boards I discovered that someone has suggested changing the permissions that the user is granting to Full Details. The default setting is Availability only.
Although this is not something I discovered on my own I figured I would share it anyway as it may help someone down the line.
Having seen this so many times I figured I would share the solution. The error message above is telling you that the file SystemManager.ks is corrupt. This file can be renamed and is located here:
Once you rename the file all you have to do it close you IE window and try again.
As you know when you installed Exchange all of the Virtual Directories use the FQDN of the server as the URLs for the Exchange Virtual Directories. If your Exchange server is being used for OWA or CAS you will most likely have a SSL Cerfiticate to prevent you from getting those pesky SSL errors.
During an install that I recently did I ran into an issue where all the outlook clients were getting SSL pop up messages that looked like this:
From the message you are able to see that the name of the certificate does not match the server name. So I logged into the Exchange Admin Center and looked under Servers > Virtual Directories and checked each of the Virtual Directories listed. As this was my first 2016 installation I discovered that there was a virtual directory for mapi. So from the web interface I changed the internal url to match the name of the certificate “https://Mail.Domain.com/mapi” and restarted IIS. After that I go and try and configure an outlook client and good news I no longer get the SSL Error, but now I am unable to authenticate to the mailbox!!!
After playing around with it for a while I discovered that changing the name back did not fix the issue so I was forced to do a rebuild on the virtual directory and that took me back to square 1.
After hours of searching online for an answer I found this powershell command that worked
Set-mapivirtualdirectory -identity “[SERVERNAME]mapi (default Web Site)” -internalurl https://Mail.DOMAIN.com/mapi
After doing this command I restarted IIS again and the clients are now able to connect without issue.
UPDATE on this issue:
I would appear that do to a misconfiguration in the client’s internal DNS their Autodiscover.domain.local was a A record and not a CNAME which it appears that outlook autodiscover does not like. So I changed the record to a CNAME by deleting the A record and recreating it. Then I went to a local machine and did a IPCONFIG /FLUSHDNS and then restarted outlook and that seems to have fixed the issue.
Recently I was working at a client who have a Windows Server 2012 R2 Essentials server not setup in as an Active Directory Domain. The client machines are Windows XP SP 3 x86 system and they are running a DOS application that is the back bone of their business. It serves as CRM, billing, and inventory system. Everything was working just fine when one of their client machines died (System Board died) so they needed to purchase a replacement system. They went with a brand new Dell Optiplex running Windows 7 x64 system.
When I went down to setup the system I discovered that the DOS program would not work (no shock there) however even compatibility mode failed me this time (although I don’t think I have ever seen it work). So my choices were to try and rebuild the system as Windows XP or build a VM that runs Windows XP. Obviously since they do not make drivers for Windows XP anymore for newer systems so I installed VMware Workstation Player on the computer and build a Windows XP virtual machine.
Once the machine was built I then needed to map a network drive to the server that was hosting the DOS application. I was able to map the drive using Windows Explorer but found out that once I did a reboot the credentials did not keep (even after checking the box that said remember credentials).
Windows XP Virtual Machine will not keep credentials for network drive after log off or reboot. The drive would continue to be mapped however end user would need to provide credentials for Server every time. Both Server and Workstation are in a Workgroup and not a Domain.
I created a logon script and placed it the startup folder of the user account that would remap the drive at every login and would use the credentials on the server to allow the workstation to access the application.
The syntax I used was:
NET USE G: \SERVERNAMESHARENAME /USER SERVERNAMEUSERNAME PASSWORD
NOTE: I was not the one who setup this network so unfortunately it was not setup the way that I would have done it so I had to jump through all these hoops to get the job done.
Recently I was picking my kids up from a family friend’s house and through normal chit chat in the conversation it was brought up that their family computer’s HDD had failed or “Crashed”. After giving them my sympathy for their loss (some work document and Tons of Family Photos and Videos) something clicked in my brain. I have been out of the game for a long time in terms of being a full time desktop support technician, not to say that I do not do it, however my sights are now on Virtualization and Messaging these days. Anyway back in the day when I used to work for large companies doing desk side support where end users would prefer to save data to their local HDD rather than network drive due to 10 Meg Ethernet or Token Ring network connection (no this is not meant to age me but rather how old the network was).
So lets just say that because this was the norm for their corporate culture we had a lot of issues with people losing data. However my team and I became very good at performing miracles and bring a drive back from the dead.
While this is still in my head I figured I would share this information with you.
Please note that I am not taking responsibility for any damage that you may do to equipment. This is just to share my war stories and if it helps someone out of a bind then great!
Drive will not spin up or there is a clicking noise
Try sticking the HDD into the freezer for a few hours (we used to do about 16 hours) and then try to power the drive up again. More times than not it will work but your time is limited so get your data quickly.
Do not put your drive on top of ice or anything moist (putting it into a plastic bag might be smart).
Drive powers on and spins with no clicking but is not detected by OS or BIOS.
Here is where working for a large company with tons of machines with the same model comes in handy. If you have a spare drive that is the same Make and Model you can use a torx screw driver to take the controller card off of the drive and put it onto the defective drive. This should allow the drive to be seen by the OS so you can get your data off.
By doing this you are voiding the warranty of your drives so make sure you know the risk before you proceed.