Category: How-to

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

Log in to you ADFS server and set a HOST SPN.

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.

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.

mac-lync-cert-chrome1

 

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.

mac-lync-cert-chrome

 

 

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.

mac-lync-cert

 

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

    1. 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 ->
    2. dnscmd /config /enableednsprobes 0  then retry your query.

 

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

 

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.

PFSense firmware URL Select

 

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

pfsense version info

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

 

 

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

 

ADSI-Exchange

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

 

 

reset permissions on Domain Partition

  1. Manage replication topology
  2. Replicating Directory Changes
  3. Replicating Directory Changes All
  4. Replicating Directory Changes In Filtered Set
  5. 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.

 

  1.  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.
  2. Using your favorite SSH Client  (Putty), connect to your VMWare ESXi 5 Host.
  3. 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.

  4. 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.
  5. 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>

     

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

     

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

  1. Verify SRV Records
    http://support.microsoft.com/kb/241515

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

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