Squidworks

[Solved] OOF – Out Of Office fails to work using Outlook 2013 and connecting to an Exchange 2007 server.

Had an issue where a customer started having issues setting OOF on a remote Exchange server 2007 when using Outlook 2013. After some digging arround and making sure all autodiscover settings and SSL settings were accuratlly set I stumbled across the issue where installed hotfixes were causing the problem. The culprit is a faulty set of updates recently pushed out by Microsoft. To be specific, the following hotfixes are Outlook 2013 (KB2837618) and Microsoft Office 2013 (KB2837643). They have to manually be uninstalled and a PC reboot issued to fix the problem.

This is for only Outlook 2013 and Exchange 2007 that I am aware of currently, others maybe affected so use wisely.

Enjoy

Cubert 😎

[LabTech] Patches not showing accurately for systems after onboarding with Ignite

I had an odd issue with a new client I had taken over from a previous MSP where after we onboarded the client Labtech showed systems as fully patched but when we scanned system using Windows update they returned with 60+ updates or more. We would then re run the inventory update and would still get all patches up to date. We noticed that the list of patches that were returned did not cover all approved patches. After some investigation we discovered that the previous MSP was using a 3rd party WSUS server and had set the server information in the registry. If the following Keys are present then you may also be seeing similar problems.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate:WUServer HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate:WUStatusServer HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdateAU:UseWUServer

Here is a Labtech script to clear out the settings and to allow you patch inventory command fetch the correct patches for your system. Execute script against each system that has been configured for a different WSUS server. Once script has completed then execute a hotfix update command from your inventory menu and wait for it to populate with the correct settings.

Download Script WSUS Settings Removal

Enjoy Cubert 😎

[Labtech]Mac Script to install Vipre Business AntiVirus.

So you want a script to install Vipre AV on Mac systems well I got just the thing for you.

Here is what I did.

Create a 2 line LT script,
In the description field of your new script type in the following, feel free to cut and paste if you want.

“I promise if this script works for me to send Cubert a Starbucks Gift card”
Now lets add our first line to the script

Line 1 = “write file” command to /tmp/myviperinstall.sh

content =

cd /tmp

curl -O http://myserver/labtech/transfer/Vipre/MacVIPREBusiness2.0.87.dmg

hdiutil attach MacVIPREBusiness2.0.87.dmgcd “/

Volumes/GFI Software VIPRE Business – 2.0.87″/

installer -pkg “GFI Software VIPRE Business Install.pkg” -target “/”

cd /tmp

sleep 5

hdiutil detach “/Volumes/GFI Software VIPRE Business – 2.0.87″/

Do not forget to edit the URL and name of the viper DMG file. I was using 2.0.87 when I wrote this so you will need to make any changes to file names and mount directory names.

*note* I left out the first line of text which normally would be (#!/bin/sh). The “Write File” function had issues with the !, not sure if I needed to escape that or not so I just left it out.

The next script line should be “Shell Extended” with a cmd of “/bin/sh /tmp/myvipreinstall.sh”

The 2 lines combined will write the script file to the Mac system and then execute the shell script. The shell script uses curl to download your DMG and then mounts DMG, and executes the PKG installer.

I am also working on updating the server preference for Mac to point to Vipre server and then updating LT database to show that AV is installed.

That will come later in the show!

Cubert

LABTECH -> How To Have A Full Screen Remote Desktop Client Redirector

Create a Labtech Full Screen RDP Redirector

Labtech out of the box comes with a older version of RDP client that when is pushed to full screen looks really crappy. That’s not Labtech’s fault but the limitation of the RDP client they packaged with the LTClient software. One of the great things about Labtech is you can customize it to your needs, Labtech does not force you to use “what they have”.

Today I will walk you through creating a new redirector in Labtech and setting up a new full screen Remote Desktop Client function. Some of the things you will need are, admin access to your LT server and a Windows 7 workstation to harvest the mstsc.exe from. As stated above the mstsc.exe supplied with LT is old and limited, we will need a new mstsc.exe to do full screen like we want.

Lets get started!

First thing we need to do is copy our Windows 7 mstsc.exe to our LTClient directory and rename it.
goto %windir%\system32\mstsc.exe and copy and paste to c:\%programfiles%\LabTech Client\RDP\mstsc1.exe

Do not overwrite the existing mstsc.exe, create a new file and name it mstsc1.exe
Now find and edit the file c:\%programfiles%\LabTech Client\RDP\LabTech.rdp, select the Display Tab and move the slider to full screen. Go back to the General Tab and select “Save As” and save as LabTech1.rdp
Do not overwrite the existing LabTech.rdp, save as a new file and name it LabTech1.rdp

Now if everything was saved correctly you should have a Labtech Client\RDP directory that looks like this.

Notice the file sizes of each mstsc.exe file?
Now come the fun stuff, creating the redirector in Labtech. Lets open up the LT Dashboard and select Config Tab -> Configuration Tab -> Redirected Apps Tab.
Lets create a new redirector using the following information.
Name: Remote Desktop(Full)

Program: %windir%\system32\CMD.exe

Arguments: /c Type “%programfiles%\LabTech Client\RDP\LabTech1.rdp”>”%temp%\%computername%.rdp” & START “RDP” /WAIT “%programfiles%\LabTech Client\RDP\mstsc1.exe” “%temp%\%computername%.rdp” /public /V:%localip1%:%localport1%

Redirector Type: Check Device, Check Computer

:Redirector Port:
Local Port = 0
LocalIP = 127.0.0.2
RemotePort= %managementport%
RemoteIP = %AltRemoteIP%
SocketType = TCP Local Listen

If all went well you should be able to reload your cache on the LT Client and then see the new redirector you created on your network redirectors menu.

Now when you launch your new redirector you should see things happen a bit differently from the original Remote Desktop connection that Labtech uses.

Your STun should be the same as any other RDP Session:

But now you should be presented with a new Remote Desktop Connection box:

Followed by a Windows Security dialog box:

Make sure to input the domain name your connecting to in with the administrator account to access system. If it populates with a previous connections domain name and you would like it to forget those credentials when new connections are created then follow my step by step instructions located on one of my other blogs -> Drop Credentials.

Now if you have multiple techs working for you and they all want the RDP full screen function then they will need a copy of the 2 files we created above. I created a Labtech script to copy the files from my LT transfer directory to the local LTClient directory as needed then push that to all tech computers so they also have the required files locally. If you ever need to update the files then it makes it easy to resend them to everyone who needs them.
Good Luck

Cubert 😎

Vitals Dashboard for Labtech MSP Providers.

Squidworks Vitals Dashboard for Labtech Software

Download SWVDB here -> SWVDB-0.1

Install instructions are included in the “install.txt” file inside of zip. You will need to have PHP 5.3.27 installed on you Labtech server and can be downloaded at http://php.net

The purpose of the Vitals Dashboard is to get key pieces of information about the health of your client base in front of you and your techs. Each time you launch your control center your dashboard can appear in the console’s display. This brings the vital information to the forefront like Offline Servers and HitmanPro alarms.

Some dashboard items are interactive and will supply more data if selected. Clicking on the HitmanPro Alarms will launch you to the HitmanPro Dashboard.

HitmanPro Dashboard

The HitmanPro Dashboard shows all the current threats found and lists them by client and computer. By clicking on the computer name you will get a detailed account of the threat alarm. At this main view level you can also see what systems were scanned in the last 24 hours and when, displayed by client.

Hitman Pro detailed alarm viewer allows you to see in detail the cause of the alarm and what threat was found. We have color coded the alarm message and added some formatting to better display the details of the alarm from the default view Labtech offers.

Agents with excessive reoccurring logs

Agents Missing Service packs or are out of date

Agents With Disk Space or Failures

I hope this helps some of you out there.

Cubert

😎

Labtech – How to access and manage VMWare ESX 5 Hosts remotely using Application Redirect

Labtech VMWare vSphere Client Redirector

Wouldn’t it be really cool if you could somehow safely access any VMWare vSphere ESX 5 host directly just using the local vSphere 5 Client installed on your workstation without porting and NATing traffic through your customers firewalls? With Labtech that is no problem, by setting up a Application Redirector you can create a new proxy that will pass all your traffic to any ESX or vCenter host and allow you to fully manage that host using your own installed vClient on your workstation, using the Labtech server and an agent, wow is it fast.

Let me show you how to do it.

I want to thank the guys over at www.labtechgeek.com for creating the outline I am following here.

1.) You will need to create a new redirected app named vSphere Client.
Goto [System Dashboard] -> [Config] -> [Redirected Apps]

2.) In the program field, enter the location of your local vShpere client like -> C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe

3.) Now we will redirect the following ports.

Local Port: 443 Local IP: 127.0.0.1 Remote Port: 443 Remote IP: %RemoteIP% Type: TCP Local Listen
Local Port: 902 Local IP: 127.0.0.1 Remote Port: 902 Remote IP: %RemoteIP% Type: TCP Local Listen
Local Port: 903 Local IP: 127.0.0.1 Remote Port: 903 Remote IP: %RemoteIP% Type: TCP Local Listen
Local Port: 8080 Local IP: 127.0.0.1 Remote Port: 8080 Remote IP: %RemoteIP% Type: TCP Local Listen
Local Port: 9443 Local IP: 127.0.0.1 Remote Port: 9443 Remote IP: %RemoteIP% Type: TCP Local Listen
Local Port: 10080 Local IP: 127.0.0.1 Remote Port: 10080 Remote IP: %RemoteIP% Type: TCP Local Listen
Local Port: 10443 Local IP: 127.0.0.1 Remote Port: 10443 Remote IP: %RemoteIP% Type: TCP Local Listen
Local Port: 902 Local IP: 127.0.0.1 Remote Port: 902 Remote IP: %RemoteIP% Type: UDP Local Listen

Redirector type should have the “Computer” box checked, this makes the redirector show up on computer consoles along side the other redirectors.

4.) Now we need to create an entry in your hosts file for the redirector to work. Add -> “127.0.0.1 vsphere-redir” to your local host file. If you just use 127.0.0.1 or localhost when the client pops up then the client may actually try to connect to the NetBIOS name of your PC, which will not work.

5.) Reload your systems cache and you should see the redirector show up under Computer consoles Redirectors menu.

To connect directly to an ESXi host, while holding the Shift click on the vSphere Client redirector from meun. This will prompt you for an IP address for the remote ESX host you want to control – enter the IP of the ESXi host.

Once you place your IP of the ESX host in the IP for Redirection box click OK. Give it a few seconds to get the proxy up and app to launch then you should see your VMware client pop up. You now type in to IPaddress/Name area “vsphere-redir” as the host IP and then the user and pass needed to log in to the ESX host.

***Note – When you’re connecting directly to a host, or to vCenter, you must always enter vsphere-redir as the IP Address/Name in the VMWare vSphere client.

***Note – If you’re connecting to a vCenter server, you won’t be able to view the console of any VMs (MKS) – this is because the vSphere Client makes a direct connection to the ESXi server on port 902. If you connect directly to the ESXi host, MKS works fine.

Enjoy,

Cubert 😎

{Solved} Appassure 5 -> Error occurred pairing to agent at URL

Replay.Core.Contracts.Agents.AgentPairingFailedException: Error occurred pairing to agent at URL

Here is several possible fixes for this type of error based on state of agent systems, Each fix is based on a given type of problem. I will continue to post other fixes for this error type as I come across them.

New Agent Install on Windows DC or SBS server.

So you just installed an Appassure 5 core server and now are trying to protect a new Windows domain controller or maybe an Microsoft SBS server and you keep getting the following errors.

There is a quick fix that worked great for me when this happened to me during a deployment to a Microsoft SBS 2011 system. Found it to be an issue when the TLS client authentication fails between Unified Communications peers where the Configure Group Policy to ignore the list of trusted certification authorities on the computer that hosts the UC client is disabled.

Open up REGEDIT on the core and agent system and add a DWord to following key.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Add Dword -> SendTrustedIssuerList with a value of zero.

Now restart the core and agent services and retry to protect server.

It should connect and add new server to core as expected.

————————————————————————————————————–

Agents Previously Paired on Another Core

If after removing an agent from protection on a Core that protects other agents, you receive an error asking you to repair the orphaned agent when you attempt to re-add it to protection on a new Core. During the repair it fails with same error “Error occurred pairing to agent at URL” and the stack trace shows the error below.

Stack Trace Error:

Call to service method https://localhost:8006/apprecovery/api/core/agents/pairing/repairOrphan POST failed: Error occurred pairing to agent at URL ‘https://anvil-hosting:8006/apprecovery/api/agent/’

Replay.Core.Contracts.Agents.AgentPairingFailedException: Error occurred pairing to agent at URL ‘https://anvil-hosting:8006/apprecovery/api/agent/’ —> WCFClientBase.HttpUnauthorizedRequestException: Call to service method https://anvil-hosting:8006/apprecovery/api/agent/pair/connect GET failed at WCFClientBase.ClientBase.HandleResponse(Uri uri, String method, HttpResponseMessage response) at WCFClientBase.ClientBase.GetResponse(Uri uri, String method, String knownEtag) at WCFClientBase.ClientBase.ExecuteServiceCall[T](Uri uri, String method) at Replay.Core.Implementation.Agents.AgentsService.VerifyPairedAgentConnectivity(AgentDescriptor agentDescriptor) at Replay.Core.Implementation.Agents.AgentsService.AddOrRepairProtectedAgent(AgentDescriptor agentDescriptor, Boolean isOrphaned)

Follow this process to to remove the connection information in the registry of the Cores and Agents involved in the moves.

On the old and new Core servers:

Open the registry editor and navigate to HKEY_LOCAL_MACHINE\Software\AppRecovery
Verify that the agent’s registry key no longer displays this specific agent ID.

On the agent systems:

Stop the Agent Service.
Open the registry editor and navigate to HKEY_LOCAL_MACHINE\Software\AppRecovery.
Export and verify that the old Core pairing is still visible under the Pairing settings.
Delete the entire agent’s key.
Start the Agent Service.

Now Protect the agent once again after all services have been restarted. You should not get any orphan or repair warnings and the system should complete without errors.

Goodluck

Cubert 😎

Copy members from one Distribution Group to another Distribution Group in PowerShell

As an Exchange and Active Directory administrator you may be asked at some point to make a new distribution group from one or more other distribution groups. Exchange 2010 and PowerShell make this a very easy task. So to get started log in to your exchange server and open your Exchange Management Console.

exchangeManagementshell

Now we need to create the new distribution group by running the following command. Replace (GroupX) with the name of the group you want to create, replace the OrganizationalUnit with the location you want the group to show up in under Active Directory and change the SAM account name to your group name.

New-DistributionGroup -Name “GroupX” -OrganizationalUnit “cornetser.com/Users” -SamAccountName “GroupX” -Type “Distribution”

Next lets list out our existing Distribution Group to see who we will be coping to the new group.

Get-DistributionGroupMember “Florida”

Now we need to add the Distribution Group Members from “Florida” distribution group to the new GroupX distribution group.

Get-DistributionGroupMember “Florida” | Get-Mailbox | Add-DistributionGroupMember “GroupX”

To add more groups to the GroupX distribution groups rerun the same command as above with new group name to copy from in the “Get-DistributionGroupMember” section. Any duplicate members will error out as a duplicate and will be skipped as the list is copied so you will have a nice clean list once completed.

Enjoy,

Cubert 8)

[Solved] Single sign-on users in Office 365 can’t sign in to Lync Online from inside their corporate network

Lync 2013 Fails to connect to service.

You installed Lync 2013 on a domain computer and it fails to connect to the Office365 Lync service. Users who connect from inside their corporate network can’t sign in to Lync Online from Lync 2013, and they receive the following error message: Cannot sign in because the server is temporarily unavailable. This issue only applies to Enterprise SSO users who sign in to Microsoft Lync Online by using Microsoft Lync 2013 from inside their corporate network. If you modify the DNS of the computer to use a public DNS address the lync client connects for 8 hours and then fails if DNS is pushed back to the domain level DNS. All internal computers have this problem with connecting where external systems do not.

AD FS 2.0 utilizes the HOST service type for SPN registration because of default Windows Communication Foundation (WCF) SPN requirements. While HTTP makes sense for web-based applications, it does not satisfy rich clients who use the WS-Trust protocol.

When you deploy an AD FS 2.0 Federation Server farm, you must specify a domain-based service account that needs a registered SPN to enable Kerberos authentication to function correctly.

setspn -s host/{your_Federation_Service_name} {domain_name}\{service_account}

Make sure that the AD FS 2.0 service is running under the domain-based service account that was mentioned in the previous step. Afterwards you will need to set the service account on the ADFS service to use the same domain service account and restart the ADFS2 services.

Configure the AD FS 2.0 server to accept request headers that are larger than 40 kilobytes (KB). Microsoft says -> The HTTP request that the user sends to the Internet Information Services (IIS) server contains the Kerberos token in the WWW-Authenticate header. Therefore, the header size increases as the number of groups increases. If the HTTP header or packet size increases beyond the limits that are configured in IIS, IIS may reject the request and send an error as the response. If the previous solutions didn’t resolve the problem, downgrade to Lync 2010 or try running Lync2013 as a Local administraor.

[Solved] – AppAssure Replay 4.7 Log write failed for device \Device\HarddiskVolume (drive ?:).

AppAssure backups stop making snapshots and you start seeing a flood of log errors in the event viewer reporting Log write failed for device \Device\HarddiskVolume (drive ?:). the failure status code is the last word of the data. an error event occurred. eventid: 0xcaa12433

I came across a website called Merrit Solutions that has a great little how-to on fixing the dreaded Log write failed for device \Device\HarddiskVolume (drive ?:) error you get in the logs when you have a System Reserve Partition with excessive or oversized AALOGS.

Thanks Merrit Solutiions for keeping this thread alive.

Here are the steps to quickly resolve the issue.

Assign a drive letter to the System Reserved Partition in diskmgmt.msc. (This is the 100 Mb partition that works with the operating system.)
Make Folders in this newly assigned drive letter visible in Explorer Folder Options (unhide hidden and system folders).
Grant your current login account full access to the System Volume Information folder through Explorer Security Tab.
Confirm the existence of excessive AALOG files or file sizes in System Volume Information Folder. (I had one AALOG file that was 77Mb.)
There should only be 1 AALOG… file, usually only a few KB in size.
If you do not see excessive or oversized AALOGS, do not proceed.
Issue “fltmc unload aafsflt” command in elevated Command Prompt (Run As Administrator) to release all of the AALOGs.
In elevated command prompt change to the disk assigned above in Step 1) and “cd Sys*”.
“del aalog*.*”to delete them.
Before closing the Command Prompt run “fltmc load aafsflt” to reload the filter driver and re-create clean new AALOGs.
When I deleted the AALOGs I got an alert from my core warning me to reboot the Agent machine.
Snapshot the machine again (you should see a Base and incrementals thereafter.)
Remove the drive letter assigned in the first step.
Restart the server or atleast restart the replay agent on server and logs should stop.