Sign in to Microsoft Lync failed because the service is not available or you may not be connected to the Internet on a Mac

How to get Lync to connect

Your company has setup an local or Office 365 Microsoft Lync service and you are having a hard time connecting to it using your Mac. When you put in your information you receive the following error back – “”Sign in to Microsoft Lync failed because the service is not available or you may not be connected to the Internet“.

I had a similar problem recently and found through digging around that actually I was having a SSL failure where the Mac was rejecting the unknown CA authority that signed Microsofts “sipdir.online.lync.com” URL used to connect to Office 365’s Lync services. We had to import the SSL into our key ring manually and then assign the always trust to the certificate.

By default the SSL imported into “Microsoft Intermediate Certificates” inside of the Key Ring Manager , you need to double click this certificate to pop the information box on the certificate, find the Trust drop down which should expose the selection boxes that will allows you to set the trust level on the certificate. Set it to Always Trust, now 2 finger click on SSL certificate and select copy certificate. Next select the System folder inside of the Key Ring Manager then 2 finger click in the right panel of the System Folder view and select paste “certificate name” so that the certificate is now in both places.

Launch Lync, place Active Directory email address in the email box and in the user ID box and your domain password to log in.

How to import the SSL cert from Microsoft.

You can download here or from a Windows box, Goto https://sipdir.online.lync.com/ in Chrome and the following should appear.

Now click the green pad lock to bring up the Permissions and Connections property box. and select the Connection tab. Then select the Certificate Information link.

This properties box should appear, select the details tab and then the copy to file button to launch the export wizard and export the SSL (using the defaults only) to a file.

Now copy that file over to your Mac or zip it up and email it to an account accessible via the Mac system and follow the import process above on all Mac systems that have issues connecting.

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

Buffer Bloat, a minis to the TCP protocol

Today I would like to take a minute of your time and talk about Bandwidth usage and a little known phenomenon called Buffer Bloat.

What is Buffer bloat and what does it effect?

Buffer bloat is the product whereby excess buffering of packets inside the network causes high latency and jitter, as well as reducing the overall network throughput. Buffer bloat occurs when a network link becomes congested, causing packets to become queued in the buffer of a router or switch. As traffic passes from one router to another this buffering can become amplified. Amplification of Buffer bloat happens as each router segment buffers the netflows, the more router segments between the endpoints the larger the bloat can grow. The problem is caused mainly by router and switch manufacturers making incorrect assumptions and buffering packets for too long in cases where they should be dropped. Dropping packets is not always a bad thing. TCP is built so that when packets are dropped the protocol slows the transmission down. Transmission speeds up and slows down until it finds an equilibrium equal to the speed of the link. However, for this to work the packet drops must occur in a timely manner and buffering packets negates this process.

In a network buffer (router memory), packets are queued before being transmitted and in the problematic situation packets are only dropped if the buffer is full. With the advent of cheap RAM router manufactures have been adding more and more RAM to their systems allowing for larger and larger buffers. On older routers, buffers were fairly small so they filled quickly and therefore packets began to drop shortly after the link became saturated, the TCP protocol could adjust, and the issue wouldn’t become apparent. On newer routers buffers have become large enough to hold several megabytes of data, which translates to 10 seconds or more at a 1 Mbit/s line rate.

The problem is not limited to just TCP, these problems also affects other protocols. All packets passing through a simple buffer implemented as a single queue will experience the same delay, so the latency of any connection that passes through a filled buffer will be affected, this includes protocols like ICMP and UDP. If you have read this please send me a email back, I would like to see how many of us out there read this far.

Want to learn more about Buffer bloat and how it effect endpoints and company networks? Please visit this article on Buffer bloat at http://gettys.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/

Quick guide to upgrading Netgate FW-7541 and FW-7535 firewalls to PFSense 2.0.+ without any special process.

I just recently ordered a new Netgate FW-7541 for our COLO that I will be using in a fail over setup. The Netgate nanoBSD build is not bad but has a few limits on packages that we wanted to overcome and also Netgate does not keep up with the PFSense updates as quickly so they are still at PFSense 2.0.1. We want our box to be running PFSense 2.0.2 so how do you do this when the it says it has the “Latest” updates from NetGate?

The trick is to change the update package location selecting the default i386 path for updates under the Firmware menu in PFSense. To do this go to the [System] menu and scroll down to [Firmware]. Now select the [Updater Settings] tab and then select from the dropdown list [Default Auto Update URLs] the (pfSense i386 Stable Updates) from the list. This will then automatically change the base URL to the new firmware location. Now save it and then retest to see if updates are available. It should now report a new version is available for install. Select the update firmware button and wait as it updates your Netgate to a full version of PFSense.

Once your system reboots you should be able to login and see your new version running.

*Note, the system may flip web admin themes on you after upgrades. To get back to the old tried and true pfSence default theme go to [System] -> [General Setup] and select pfSense_ng from the themes list and save. This will return you to the standard theme.

Enjoy,

Cubert 😎

Turning DNS into a weapon of mass destruction

I wanted to send out a little blurb about the latest attack on Spamhaus this week and to enlighten you on just how something like this is done. Don’t we all love to learn new things!

As a lot of you have been hearing, Spamhaus was attacked this week by the group Anonymous with what is commonly known as a DNS Reflection attack. What is a DNS reflection attack you ask? Let’s me explain. DNS reflection AKA DNS Amplification is a process where an attacker makes requests to open DNS servers on the internet (4.2.2.2) using spoofed IP address as the address the request comes from. This in turn generates a set of packets back to the spoofed address (the victim) with the results of the DNS query. On the top this would look to be fairly harmless, the only thing really being done here is a fake requests that spawn a reply from the public DNS server back to the victim.

The attack come in the form of the “Amplification effect” that these queries have on your network. The “amplification” in DNS amplification attacks is generated by the size of those responses. While a DNS lookup request itself is fairly small, the resulting response of a recursive DNS lookup can be much larger. A relatively small number of attacking systems sending a trickle of forged UDP packets to open DNS servers can result in a firehose of data being blasted at the victim. A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60 so you can quickly see that with a few systems under ones control you could drop a DDOS on any network that would cripple their router and take down their network access.

So now you know, enjoy the knowledge.

Cubert. 😎

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

[Solved] – Dcdiag fails for NCSecDesc test and adprep /rodcprep fails to fix it.

This was a real pain and we ended up having to call Microsoft and spend several hours to resolve what seem to be a simple issue. When running dcdiag you get an error that the NCSecDesc test failed with:

Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have Replicating Directory Changes In Filtered Set access rights for the naming context: DC=cosgro,DC=com

Normally running adprep /rodcprep at the command line would correct the issues but in this case we kept getting the same response when running adprep.

Adprep detected the operation on partition DC=ForestDnsZones,DC=cosgro,DC=com has been performed. Skipping to next partition. ============================================================================== Adprep detected the operation on partition DC=DomainDnsZones,DC=cosgro,DC=com has been performed. Skipping to next partition. ============================================================================== Adprep detected the operation on partition DC=cosgro,DC=com has been performe d. Skipping to next partition. ============================================================================== Adprep completed without errors. All partitions are updated. See the ADPrep.log in directory C:\Windows\debug\adprep\logs\20130213141646 for more information.

And when we re ran DCDiag we would still get the same error. All the online documents say this should of resolved the issues but it had not.

The problem was not the ADPrep /rodcprep but the permissions were seen to be to “open” for the Enterprise Domain Controllers Group. The security permissions for this group was set to “full” on the main domain partition. This set of permissions needed to be more restrictive for the group. To fix we needed to open ADSI Edit and reset the permissions on the domain partition.

The picture below shows you where the domain partition resides, right click the partition and select properties.

Then on the pop up windows select the security tab. In the Groups and Users box find the “Enterprise Domain Controllers” group and then uncheck all permissions.

Now re-add only the list below to the allow column.

Manage replication topology
Replicating Directory Changes
Replicating Directory Changes All
Replicating Directory Changes In Filtered Set
Replication Synchronization

Apply the changes and rerun DCDiag to verify that the changes are working.

Thats it.

Enjoy Cubert 😎

[Solved] ESX VM shutdown stopped at 95% – VM fails to restart

We have several customers on sketchy hardware and on occasion the VM crash due to a SCSI card issue with the mother board used, that aside we have from time to time a need to force a hard reboot of the server running in a VM. Some times it works great and sometimes we have a lockup at 95% and have to force a kill of process that runs the VM to get it to restart.

So here is the process we take to get this to free up and reboot the VM on ESXi 5.0 and later VMware hosts.

Make sure if you do not already have it turned on, to turn on SSH on the ESXi Host. This can be done via the [Configuration -> [Security Profile] using the VMware client.
Using your favorite SSH Client (Putty), connect to your VMWare ESXi 5 Host.
We now need to get and kill the process group for the VM that has failed. To do this we will look for the process group ID using this command.

execute -> ps -g|grep “VMName”You should get a return that looks similar to this.

3372 vmm0:MyVMSystem
3374 3368 vmx-vthread-4:MyVMSystem 3368 3368 /bin/vmx
3375 3368 vmx-mks:MyVMSystem 3368 3368 /bin/vmx
3376 3368 vmx-vcpu-0:MyVMSystem 3368 3368 /bin/vmx

We are looking for the common number across all processes and in this case that would be “3368” as seen near the end of each line.
Now will need to kill the process. To do this we need to execute -> kill -9 3368 Replace “3368” with the ID number of your system.
Now we need to do some clean up, We need to delete the swap file in the directory where the VM is stored. To get to where we store the swap file you will need to do the following.execute ->cd /vmfs/volumes/<YourDataStore>/<VMName>
Next we need to make sure what our swap file name is so execute -> ls

This will give you a directory listing find your swap file by looking for the file extension “.vswp”. Now we will remove it with this command.

execute -> rm –r <YourSwapFile.vswp>
Now lets restart our VM services, This will not affect any running VM and is safe to run while VMs are active on host.execute -> /sbin/services.sh restart
Reconnect your VMware client to the host and complete the process to power on the VM by first removing the VM from the inventory (Do not Delete from Disk) and re-adding it back in. This will reset the VM fully and allow you to restart it. After you remove your VM from inventory you can re-add it by browsing the datastore in your VMWare client finding your VM directory and right clicking on the “.vmx” file. A menu will pop up and you can click “Add to Inventory” which will place VM back into the available VMs list. Now select the VM and click the Boot up arrow button to get started again.

Enjoy,

Cubert 😎

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 😎

DCDiag fails with the host could not be resolved to an IP address check the DNS server, DHCP, server name, etc although the guid dns name couldn’t be resolved.

You run DCDiag and it returns a failure that names can not be resolved.

  
   testing server: default-first-site-name\mydomain
      starting test: connectivity
         the host 7397e120-1c8d-4f2d-b8cb-d829d16d949a._msdcs.mydomain.local could not be resolved to an
         ip address.  check the dns server, dhcp, server name, etc
         although the guid dns name
         (7397e120-1c8d-4f2d-b8cb-d829d16d949a._msdcs.mydomain.local) couldn't be
         resolved, the server name (myhost.mydomain.local) resolved to the ip
         address (192.168.1.5) and was pingable.  check that the ip address
         is registered correctly with the dns server. 
         ......................... myhost failed test connectivity

This is mainly due to bad or non existent DNS records on your AD server. Here are the steps to run through to make sure your Active Directory DNS has the correct records needed to allow Active Directory to function correctly in a Windows 2003 or Windows 2008 environment.

Steps to resolve:

Verify SRV Records
http://support.microsoft.com/kb/241515
SRV Records missing after Promo
http://support.microsoft.com/kb/241505
Verify All DC’s are point to one as “master”, Second to them self or another is better.
Verify DHCP Client Service is running (needed for Dynamic DNS updates)
Run at cmd prompt -> net stop netlogon && net start netlogon
Run at CMD prompt -> netdiag /fix
Re run at CMD prompt -> DCDiag.exe

You should now get a passing test when you run dcdiag.exe. You may see the following response to the dcdiag.exe execution.

Testing server: Default-First-Site-Name\MYDOMAIN
Starting test: Connectivity
*** Warning: could not confirm the identity of this server in
the directory versus the names returned by DNS servers.
If there are problems accessing this directory server then
you may need to check that this server is correctly registered
with DNS
……………………. MYHOST passed test Connectivity

Enjoy

Cubert 😎