APPAssureD – Dell AppAssure Backup Plugin For LabTech

A new plugin is under development here inside the Squidworks garage that allows Labtech MSPs to manage Dell Appassure Backup Cores servers from a common console inside of Labtech. The new plugin leverages Appassure REST API to mine data from each core and send that data back to the Labtech database. Using the same processes the plugin is able to send commands back to the cores to preform various tasks like start a new backup or replication.

The plugin provides a common view of each core at the location level console in Labtech. You can select one of many cores at any location and view the protected servers managed by that core. Selecting a protected server provides details about that server and the list of snapshots preformed on that system. We have many great features planed for this plugin so start following us now!

Client Console

Dashboard View

The plugin is still under development and will we have a release for early beta testers. Place a comment here you would like to be notified of updates and being included in the beta testing.

Get Version 1.0.1 Beta here

You Will need Powershell 3 on all Cores, Here is a script to install Powershell 3 directly from LabTech

Get PS Installer Script Here

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

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

{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)

DNSWalk : Help Resolve Microsoft Windows DNS Issues And Resolution Failures

Microsoft DNS Server Cannot Resolve Some Domain Names Externally

DNSWalk is a small windows application that queries all ROOT servers and all returned Top Level Domain (TLD) servers for the FQDN requested. This allows you to see what is being returned to you from all root hint servers and all Top level DNS server.

Download -> DNSWalk-1.0

If you run DNSWalk on a Windows DNS server it will automatically read in the root hints file and use that. If you want to run it on another server you can specify the root hints file to use.

To use it unzip the attachment and at the command line type DNS.exe test=www.google.com substitute www.google.com with the domain you want to test resolution of.

If you want to compare the results from a client to what were seeing, copy there root hints file to your pc and run the command like this

DNS.exe test=www.google.com hints=c:\copiedhintsfile

By default in c:\windows\system32\dns\cache.dns. The tool will output a file called report.html in the same folder it was run from. Attached is an example.

Microsoft DNS has 2 big issues I have seen with DNS

Some DNS name queries are unsuccessful after you deploy a Windows Server 2003 or Windows Server 2008 R2-based DNS server
This issue occurs because of the Extension Mechanisms for DNS (EDNS0) functionality that is supported in Windows Server 2003 DNS. EDNS0 permits the use of larger User Datagram Protocol (UDP) packet sizes. However, some firewall programs may not permit UDP packets that are larger than 512 bytes. As a result, these DNS packets may be blocked by the firewall.To fix, Open up CMD windows and type the following ->
dnscmd /config /enableednsprobes 0 then retry your query.

Microsoft DNS Server Cannot Resolve Some Domain Names When External DNS has different source IP address.
This problem occurs because some implementations of DNS include a load balancing feature. In implementations such as this, the server that answers a query outside the firewall can be different than the server to which the query was originally addressed. Under these circumstances, a firewall may discard the reply from the external DNS server. The packet is discarded because the internal host (the DNS server inside the firewall) originally opened the connection to a different destination IP address than the IP address the reply was received on (the first external DNS server). This causes the reply from the external DNS server to never be received on the DNS server on the inside of the firewall.

To fix: Either add a Forwarder to your DNS or at your Firewall add NAT rul to send all port 53 traffic to internal DNS server. This will then negate the firewall blocks.

A example of the DNS report DNSWalk reports back:

DNS REPORT

Root hint servers

A.ROOT-SERVERS.NET. – 198.41.0.4

B.ROOT-SERVERS.NET. – 128.9.0.107

C.ROOT-SERVERS.NET. – 192.33.4.12

D.ROOT-SERVERS.NET. – 128.8.10.90

E.ROOT-SERVERS.NET. – 192.203.230.10

F.ROOT-SERVERS.NET. – 192.5.5.241

G.ROOT-SERVERS.NET. – 192.112.36.4

H.ROOT-SERVERS.NET. – 128.63.2.53

I.ROOT-SERVERS.NET. – 192.36.148.17

J.ROOT-SERVERS.NET. – 192.58.128.30

K.ROOT-SERVERS.NET. – 193.0.14.129

L.ROOT-SERVERS.NET. – 198.32.64.12

M.ROOT-SERVERS.NET. – 202.12.27.33

Top Level servers from A.ROOT-SERVERS.NET.

– m.gtld-servers.net

192.55.83.30

com

– l.gtld-servers.net

192.41.162.30

com

– k.gtld-servers.net

192.52.178.30

com

– j.gtld-servers.net

192.48.79.30

com

– i.gtld-servers.net

192.43.172.30

com

– h.gtld-servers.net

192.54.112.30

com

– g.gtld-servers.net

192.42.93.30

com

– f.gtld-servers.net

192.35.51.30

com

– e.gtld-servers.net

192.12.94.30

com

– d.gtld-servers.net

192.31.80.30

com

Top Level servers from B.ROOT-SERVERS.NET.

DNS request timed out.

timeout was 2 seconds.

Server: UnKnown

Address: 128.9.0.107

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

Top Level servers from C.ROOT-SERVERS.NET.

– l.gtld-servers.net

192.41.162.30

com

– g.gtld-servers.net

192.42.93.30

com

– k.gtld-servers.net

192.52.178.30

com

– f.gtld-servers.net

192.35.51.30

com

– j.gtld-servers.net

192.48.79.30

com

– i.gtld-servers.net

192.43.172.30

com

– e.gtld-servers.net

192.12.94.30

com

– d.gtld-servers.net

192.31.80.30

com

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– b.gtld-servers.net

192.33.14.30

2001:503:231d::2:30

com

Top Level servers from D.ROOT-SERVERS.NET.

– c.gtld-servers.net

192.26.92.30

com

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– h.gtld-servers.net

192.54.112.30

com

– d.gtld-servers.net

192.31.80.30

com

– e.gtld-servers.net

192.12.94.30

com

– j.gtld-servers.net

192.48.79.30

com

– m.gtld-servers.net

192.55.83.30

com

– g.gtld-servers.net

192.42.93.30

com

– k.gtld-servers.net

192.52.178.30

com

– l.gtld-servers.net

192.41.162.30

com

Top Level servers from E.ROOT-SERVERS.NET.

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– i.gtld-servers.net

192.43.172.30

com

– k.gtld-servers.net

192.52.178.30

com

– l.gtld-servers.net

192.41.162.30

com

– f.gtld-servers.net

192.35.51.30

com

– d.gtld-servers.net

192.31.80.30

com

– j.gtld-servers.net

192.48.79.30

com

– c.gtld-servers.net

192.26.92.30

com

– e.gtld-servers.net

192.12.94.30

com

– h.gtld-servers.net

192.54.112.30

com

Top Level servers from F.ROOT-SERVERS.NET.

– m.gtld-servers.net

192.55.83.30

com

– i.gtld-servers.net

192.43.172.30

com

– e.gtld-servers.net

192.12.94.30

com

– f.gtld-servers.net

192.35.51.30

com

– d.gtld-servers.net

192.31.80.30

com

– b.gtld-servers.net

192.33.14.30

com

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– l.gtld-servers.net

192.41.162.30

com

– g.gtld-servers.net

192.42.93.30

com

– c.gtld-servers.net

192.26.92.30

com

Top Level servers from G.ROOT-SERVERS.NET.

– e.gtld-servers.net

192.12.94.30

com

– g.gtld-servers.net

192.42.93.30

com

– b.gtld-servers.net

192.33.14.30

com

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– j.gtld-servers.net

192.48.79.30

com

– h.gtld-servers.net

192.54.112.30

com

– m.gtld-servers.net

192.55.83.30

com

– d.gtld-servers.net

192.31.80.30

com

– c.gtld-servers.net

192.26.92.30

com

– l.gtld-servers.net

192.41.162.30

com

Top Level servers from H.ROOT-SERVERS.NET.

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– b.gtld-servers.net

192.33.14.30

com

– c.gtld-servers.net

192.26.92.30

com

– d.gtld-servers.net

192.31.80.30

com

– e.gtld-servers.net

192.12.94.30

com

– f.gtld-servers.net

192.35.51.30

com

– g.gtld-servers.net

192.42.93.30

com

– h.gtld-servers.net

192.54.112.30

com

– i.gtld-servers.net

192.43.172.30

com

– j.gtld-servers.net

192.48.79.30

com

Top Level servers from I.ROOT-SERVERS.NET.

– c.gtld-servers.net

192.26.92.30

com

– f.gtld-servers.net

192.35.51.30

com

– j.gtld-servers.net

192.48.79.30

com

– l.gtld-servers.net

192.41.162.30

com

– e.gtld-servers.net

192.12.94.30

com

– h.gtld-servers.net

192.54.112.30

com

– m.gtld-servers.net

com

– i.gtld-servers.net

192.43.172.30

com

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– b.gtld-servers.net

192.33.14.30

2001:503:231d::2:30

com

Top Level servers from J.ROOT-SERVERS.NET.

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– b.gtld-servers.net

192.33.14.30

com

– c.gtld-servers.net

192.26.92.30

com

– d.gtld-servers.net

192.31.80.30

com

– e.gtld-servers.net

192.12.94.30

com

– f.gtld-servers.net

192.35.51.30

com

– g.gtld-servers.net

192.42.93.30

com

– h.gtld-servers.net

192.54.112.30

com

– i.gtld-servers.net

192.43.172.30

com

– j.gtld-servers.net

192.48.79.30

com

Top Level servers from K.ROOT-SERVERS.NET.

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– b.gtld-servers.net

192.33.14.30

com

– c.gtld-servers.net

192.26.92.30

com

– d.gtld-servers.net

192.31.80.30

com

– e.gtld-servers.net

192.12.94.30

com

– f.gtld-servers.net

192.35.51.30

com

– g.gtld-servers.net

192.42.93.30

com

– h.gtld-servers.net

192.54.112.30

com

– i.gtld-servers.net

192.43.172.30

com

– j.gtld-servers.net

192.48.79.30

com

Top Level servers from L.ROOT-SERVERS.NET.

DNS request timed out.

timeout was 2 seconds.

Server: UnKnown

Address: 198.32.64.12

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

Top Level servers from M.ROOT-SERVERS.NET.

– l.gtld-servers.net

192.41.162.30

com

– g.gtld-servers.net

192.42.93.30

com

– j.gtld-servers.net

192.48.79.30

com

– a.gtld-servers.net

192.5.6.30

2001:503:a83e::2:30

com

– b.gtld-servers.net

192.33.14.30

com

– c.gtld-servers.net

192.26.92.30

com

– d.gtld-servers.net

192.31.80.30

com

– k.gtld-servers.net

192.52.178.30

com

– m.gtld-servers.net

192.55.83.30

com

– f.gtld-servers.net

192.35.51.30

com

Third Level servers

192.55.83.30

192.41.162.30

192.52.178.30

192.48.79.30

192.43.172.30

192.54.112.30

192.42.93.30

192.35.51.30

192.12.94.30

192.31.80.30

192.5.6.30

192.33.14.30

192.26.92.30

Third Level servers from 192.55.83.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.41.162.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.52.178.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.48.79.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.43.172.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.54.112.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.42.93.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.35.51.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.12.94.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.31.80.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.5.6.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.33.14.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

Third Level servers from 192.26.92.30

– ns2.google.com

216.239.34.10

google.com

– ns1.google.com

216.239.32.10

google.com

– ns3.google.com

216.239.36.10

google.com

– ns4.google.com

216.239.38.10

google.com

[Solved] Event ID’s 5015 & 5016 Microsoft Exchange 2010 cannot find a route to the source transport server or home MTA server

We were getting the following error after a migration to Exchange 2010 from 2003 which indicated that Exchange was still looking for the old server.

Event: Microsoft Exchange cannot find a route to the source transport server or home MTA server

The problem is during the migration the old server didn’t get pulled from Active Directory correctly so there were still settings that caused Exchange to believe that there was another MTA available.

To resolve we opened up ADSI Edit on the AD server and navigated to the following container:

[Configuration][CN=Configuration,DC=xxx,DC=local][CN=Services][CN=Microsoft Exchange][CN=MyDomainName][CN=Connections]

Inside this container you may find entries that reference your old server. Just delete them and you should be good.

How to fix NCSECDESC Failures in Active Directory after DCDiag reports a failure.

How to fix NCSECDESC Failures in Active Directory. If you get the following when running DCDiag on a Windows AD Server do the following to correct.

Starting test: NCSecDesc
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=ForestDnsZones,DC=MYDOMAIN,DC=local
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=DomainDnsZones,DC=MYDOMAIN,DC=local …………………….
MYHOST failed test NCSecDesc

Download fixfsmo.vbs and find or download ADPREP for your distribution of windows.

First run “cscript fixfsmo.vbs DC=DomainDnsZones,DC=MYDOMAIN,DC=local ” Change only the domain name to match domain, leave [DC=DOMAINDNSZONES]

Next run “cscript fixfsmo.vbs DC=ForestDnsZones,DC=MYDOMAIN,DC=local ” Change only the domain name to match domain, leave [DC=FORESTDNSZONES]

Next locate your ADPREP directory and change to\adprep, now run adprep /rodcprep . If you do not have the ADPREP tools you can get them from Microsoft’s website or on the original CD media your server came with.

Then rerun DCDiag to verify that the failures are gone.

Enjoy,

Cubert 😎