How-to Archives - Page 3 of 13

[How-to] Relay mail from copiers or scanners through Office 365

Sending mail from network devices through Office 365

You just completed a migration to Office 365 for all your users but now you need to relay mail from network devices like copiers and scanners. You will need to setup a relay connector in Office 365 to allow these simple SMTP devices to relay mail to you or other 3rd party email addresses.

Below is the basic instructions on how to allow mail from a known IP address to pass through your Office 365 Exchange service.

Obtain the public IP address you’re using when mail goes out from scanner.
Log on to the Office 365 Portal.
Select Domains. Highlight one of your domains and use the wizard to obtain your MX record. The MX record will look similar to contoso.com.mail.protection.outlook.com. Make a note of the MX record for later.
In the upper right, select Admin and then select Exchange from the drop down.
In the Exchange Admin Center, select Mail Flow > Connectors.
If no inbound connector exists, create one.
1. Give the connector a name.
2. Select On-Premises for the Connector Type.
3. Under Domains, add a single asterisk (*). This will allow sending to any domain. Other values in this field will limit the domains that you can send mail to.
4. In the IP Addresses section, add the IP address from Step 1.
5. Leave all the other fields with their default values and select Save.
In the DNS for your domain, I suggest that you modify your SPF record to include the IP address from Step 1. The finished string should look similar to this: v=spf1 ip4:10.1.2.3 include:spf.protection.outlook.com ~all where 10.1.2.3 is your public IP address. Skipping this step could cause email to be sent to recipients’ junk mail folders.
In the device’s settings, specify a Smart Host value equal to the MX record value you recorded in Step 3.
That’s it!

Enjoy

Cubert 😎

[Solved] Remote Web Workplace Stops Working on Windows SBS 2011with EventID 1309

When users attempts to click on the “Connect” link under “Computers” in attempts to launch remote web workplace nothing seems to happens. If you issue a IISreset then the system starts working again for a short time before starting to fail again. You check your logs and find EventID 1309 Event message: An unhandled exception has occurred.

It appears that it maybe some level of memory issue in .Net 4.5 and the Remote Access web.config set to default at a given memory level.

To Fix:

Edit (via NotePad) the web.config file located at “C:\Program Files\Windows Small Business Server\Bin\WebApp\RemoteAccess

Look for the following line at the bottom of web.config

<serviceHostingEnvironmentaspNetCompatibilityEnabled=”true” />

Replace that line with: (all on one line)

<serviceHostingEnvironment aspNetCompatibilityEnabled=”true” minFreeMemoryPercentageToActivateService=”0″ />

Save file and then restart the World Wide Web services to activate the changes.

Your Remote Web Workplace should now stay functional.

Enjoy..

Cubert 😎

[How-to] PFSense OpenVPN Site-to-Site with (DHCP) Dynamic Internet Address

Setting up an OpenVPN site to site connection when one side is using DHCP to acquire an Internet IP Address in 5 minutes or less.

Here is the 5 minutes How-to on setting up 2 PFSense devices with a site to site VPN. For this example I will be using 2 Netgate m1n1wall systems that utilizes PC Engines ALIX 2D13 network boards with 3 LANs. Both are connected directly to the Internet via the WAN port and have assigned Internet IP addressing, they also have a private LAN segment that will be routed over the VPN so that site A and site B can see each other.

OpenVPN is a Client/Server type of process where 1 device acts as the server and the other acts as a client. Servers provide a service and clients connect to that service. If a server is using DHCP to get a Internet IP address then it must have a host name that is always resolvable or you risk dropping the tunnel between clients and this server. For this example we are assuming that the server device has a static IP address and that the client is using DHCP to obtain it’s Internet address.

First we build the server (Device A)

1. Go to the VPN tab and select OpenVPN, Select the server tab and then click the [+] symbol to start the process to create a new server instance.

2. Next we will fill out the information as it fits our network. The highlighted areas are required to create a successful VPN server.

Server Mode = Peer to Peer(Shared Key)

Protocol = UDP

Interface = WAN

Local Port = 1194

Description = Friendly Name (Anything)

Tunnel Network = 10.10.0.0/24 (Must be a new private network not currently in use)

Local Network = Server’s LAN subnet (You may have multiple LAN Networks so select the Network this VPN applies to)

Remote Network = Client’s LAN Subnet

3. Once saved you should have a new server listed under you OpenVPN server tab.

4. Select the [e] to edit this VPN, we will be copying the newly created “Shared Key” from the configurations to use when we create the client. In the middle of the configuration will be the shared key. Copy this key.

5. Next we need to create a WAN firewall rule on the server to allow UDP port 1194 to pass.

6. We will now have a new firewall rules tab called [OpenVPN], we will need to add an allow rule to pass traffic across the VPN tunnels. For the purpose of this how-to we will use a full allow rule to get all traffic to pass. You can firewall this tab as needed once we have verified traffic flows.

Now let’s build the client (Device B)

1. On the client device (DHCP Enabled) from the VPN menu select OpenVPN, find the client tab and select the [+] to create a new client configuration.

2. Next we will fill out the information as it fits our network. The highlighted areas are required to create a successful VPN client.

Server Mode = Peer to Peer (Shared Key)

Protocol = UDP

Device Mode = tun

Interface = WAN

Server Host = Internet IP of OpenVPN Server

Server Port = 1194

Description = Friendly Name (Anything)

Tunnel Network = 10.10.0.0/24 (Same as the server side)
*note both side should have same network with no host
IP provided, The server and client will auto-negotiate
the actual ending address (example 10.10.0.1 & 10.10.0.2).

Remote Network = Servers LAN subnet

3. Save configuration, return to the client tab under OpenVPN and select the [e] under the new client VPN configuration.

4. Copy the Shared Key from the server to this box, overwrite any key that may currently exist in box.

5. Add a firewall rule under WAN of client (Not really required) to allow UDP port 1194.

VPN is now ready to use

Once the configurations are complete the tunnel should automatically start up and you should no be able to see the status of the VPN. Under the [Status] main menu select OpenVPN to see all active VPNs.

As you can see from the image the tunnel is up, the Virtual Addr did auto negotiate an IP address of 10.10.0.1 and bytes are being sent across tunnel. If you have issues passing traffic (ping) from one network to another and you show an active VPN running under status then most likely a simple reboot of each firewall will clear any routing issues and the tunnels will start working fine afterwards.

Good luck and Happy VPNing!!

Cubert 😎

[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 😎

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)