Fixing case in Windows DNS entries

There is almost no legitimate reason to spend time “correcting” the case (uppercase, lowercase, CamelCase) of DNS entries, in fact there aren’t any I can think of at the moment.

That said, maybe you find yourself in a position where a DNS entry in Windows Server does not appear in the way you would prefer.  Deleting the entry in the DNS MMC and re-registering the entry they way you’d like it often doesn’t alter the original format.  The reason here is the first time a server performs a dynamic registration/update of its DNS name in an AD integrated zone, an object is created in that zone.  Deleting that entry manually (or letting it expire) results in the entry being dnsTombstoned and not truly deleted, not yet anyway.

dnsTombstoned

If DNS Scavenging is configured, that object will eventually be removed permanently, if not, the object is essentially immortal.  When you re-register the same name, the original object is re-animated (dnsTombstoned = <not set>, or I’ve also seen “FALSE”) causing the original format of the name to come back.

Here’s how to go about “fixing” that.

Each AD object representing a DNS entry is stored in a specific place in AD, based on the replication scope of that particular zone.

Zone replication scope
Location in Active Directory
All DNS servers in the Active Directory forest
Replicates zone data to all DNS servers that are running on domain controllers in the Active Directory forest. Usually, this is the broadest scope of replication.
DC=<zone name>,CN=MicrosoftDNS,DC=ForestDnsZones,DC=<domain>,DC=<domain>
All DNS servers in the Active Directory domain
Replicates zone data to all DNS servers that are running on domain controllers in the Active Directory domain. This option is the default setting for Active Directory–integrated DNS zone replication in Windows Server 2003 and Windows Server 2008.
DC=<zone name>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=<domain>,DC=<domain>
All domain controllers in the Active Directory domain
Replicates zone data to all domain controllers in the Active Directory domain.
DC=<zone name>,CN=MicrosoftDNS,CN=System,DC=<domain>,DC=<domain>

The individual entries have objects one level deeper e.g. DC=MYSERVER,DC=mydomain.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=mydomain,DC=com

If you wanted to change that server name to lowercase e.g. “myserver”, the DC=MYSERVER,DC=mydomain.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=mydomain,DC=com object would need to be removed, also potentially replicated to the rest of the relevant servers and then I reloaded the zone just to make sure.

At that point I could re-register with the name in the format I wanted.

Configuring Cisco WebEx Meeting Server to work with ADFS 2.0+

Fantastically useful set of instructions! If only Cisco’s own docs were this good…

Digital Glue

Like so many other things I’ve written about, this is another example of where I was unable to find a solid set of instructions online about how to do something and had to assemble a working solution from a number of fragments spread across vendor-provided information, blog posts and cries for help posted in online forum threads.  Hopefully this can spare at least a few others from having to go through the same thing.

This procedure has been used to create a system that works on the “first try” so I know that it works.  It’s possible that this could be further refined with some additional testing.

This post is targeted to the on-premise version of the Cisco WebEx meeting server, not the hosted (SaaS) version.  I believe that most of what is here should be applicable to the hosted version but there are apparently some differences in the configuration…

View original post 1,227 more words

Clearing up Event 36887 – Schannel The following fatal alert was received: 48

event36887-general

Schannel errors in Event Viewer tend to be really unhelpful.  From MSDN, Error 48 indicates TLS1_ALERT_UNKNOWN_CA  SEC_E_UNTRUSTED_ROOT  0x80090325 so most likely due to a self-signed, or internal CA signed certificate on the host in question.  But it doesn’t indicate which client computer is triggering the error.

However, you can get fairly precise time out of the XML view under the details tab (TimeCreated SystemTime gives the time with lots of decimal places making it way easier to find the offending traffic in a network capture.

event36887-details-xml

To find it in Wireshark, change the Time Display Format to  “Date and Time of Day” in the View Menu (Ctrl+Alt+1) and filter by “ssl”  The timestamps aren’t identical (plus the event log entry isn’t adjusted to the local timezone), but it’s close enough that you shouldn’t have trouble finding it.  The particular traffic I was seeing looked like this.

2014-06-11 12:00:25.774832 192.168.1.100 192.168.1.10 TLSv1 73 Alert (Level: Fatal, Description: Unknown CA)

The first IP above (192.168.1.100) is the remote client which is triggering the issue.  The second IP (192.168.1.10) is the local machine.  Then just had to sort out adding the internal CA cert to the client machine. Fixed!

Why are my LUNs offline because of policy?

Here’s something I’ve been seeing off and on since Exchange 2007.  After a reboot, The LUNs presented off the SAN sometimes appear in Disk Management with the note “The disk is offline because of policy set by an administrator” and you end up needing to manually online each disk.

There are a number of blog posts and such indicating that you need to change the SAN Policy of the server.  The default being “Offline Shared” on Enterprise and Datacenter editions of Windows Server.

The recommendation of these posts being to set the san policy to “Online All” to solve the problem.  This done as prescribed by http://technet.microsoft.com/en-us/library/gg252636.aspx.

diskpart
san
san policy=OnlineAll

After a reboot I would find that the problem persisted, the volumes would still show as offline with the same note about policy.  What wasn’t obvious from all those posts was that each disk has its own registry bit indicating that each disk has it’s own setting related to san policy which is apparently set when the disk is discovered. The values are described below.

  VDS_SP_UNKNOWN         = 0x0
  VDS_SP_ONLINE          = 0x1
  VDS_SP_OFFLINE_SHARED  = 0x2
  VDS_SP_OFFLINE         = 0x3

1,2 and 3 are somewhat obvious, but 0, VDS_SP_UNKOWN seems to indicate that for that disk, the value is undefined so to speak and that it follows the system san policy.

So it appears that in my case, with the default at Offline Shared, disks inherit that setting and regardless of what the system san policy is set to afterward, the disk remembers Offline Shared.

Found another KB article which points out that fact AND includes a quick powershell script to fix it.  http://support.microsoft.com/kb/2849097

You’ve got to dig out the string indicating your vendor from the registry, but that’s easy to find under HKLM:\SYSTEM\CurrentControlSet\Enum\SCSI


					

The number of people who run Exchange without a DAG is mindboggling.  I’ve run into several business, running Exchange 2010/2013 which don’t use DAGs at all.  Even if there’s only one location, why?

Exchange 2013 – OWA and ECP logins fail with 500 error

exchange-2013-500-error

After troubleshooting another issue, and having one of the 2013 servers crash a few times while running diagnostics, OWA and ECP logons started showing an error.

500 Unexpected Error :( An error occurred and your request couldn’t be completed. Please try again.

Reseting IIS, restarting the servers, clearing cookies etc had no effect.

Event 4 appears in the Application log at the time of the login.

Current user: 'Example.com/Test User'
Request for URL 'https://server01.example.com:444/ecp/default.aspx(https://server01/ecp/)' failed with the following error:
System.NullReferenceException: Object reference not set to an instance of an object.
 at Microsoft.Exchange.Clients.Common.Canary15.Init(Byte[] userContextIdBinary, Byte[] timeStampBinary, String logonUniqueKey, Byte[] hashBinary, String logData)
 at Microsoft.Exchange.Clients.Common.Canary15..ctor(String logonUniqueKey)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpCookie(HttpCookie cookie, String logonUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpContext(HttpContext httpContext, String logOnUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary15(HttpContext context, Boolean shouldRenew, String canaryName)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary(HttpContext context)
 at Microsoft.Exchange.Management.ControlPanel.RbacModule.Application_PostAuthenticateRequest(Object sender, EventArgs e)
 at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
 at Microsoft.Exchange.Clients.Common.Canary15.Init(Byte[] userContextIdBinary, Byte[] timeStampBinary, String logonUniqueKey, Byte[] hashBinary, String logData)
 at Microsoft.Exchange.Clients.Common.Canary15..ctor(String logonUniqueKey)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpCookie(HttpCookie cookie, String logonUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpContext(HttpContext httpContext, String logOnUniqueKey, Canary15Profile profile)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary15(HttpContext context, Boolean shouldRenew, String canaryName)
 at Microsoft.Exchange.Management.ControlPanel.CanaryExtensions.CheckCanary(HttpContext context)
 at Microsoft.Exchange.Management.ControlPanel.RbacModule.Application_PostAuthenticateRequest(Object sender, EventArgs e)
 at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
 at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

The error appears to be related to corrupt attributes in Active Directory, specifically under CN=Client Access,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>. The attribute msExchCanaryData0, or msExchCanaryData1, 2, 3, etc.  can contain bad data.

500-error-adsiedit

As always, be safe, have an AD backup you can rely on.  Then proceed to to clear the value of all the msExchCanaryData# attributes (shown above in ADSIEdit).  Then the App Pool(s) for MSExchangeECPAppPool and MSExchangeOWAAppPool need to be recycled by going into IIS Manager and right-clicking each pool, then choosing “Recycle…” At this point all was sorted out for me.

500-error-apppools

 

Found info regarding the issue on TechNet:  http://social.technet.microsoft.com/Forums/exchange/en-US/777b51ee-330d-43cc-a56e-4614d44aed7b/unable-to-access-owa-or-ecp-something-went-wrong-or-500-unexpected-error?forum=exchangesvrclients