Recently ran into an issue when attempting to run Setup.exe /PrepareAD for Exchange 2013 Cu5. As with all new Exchange updates, the expectation is that there will be schema updates included.
Upon running the Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD command I get this error.
Performing Microsoft Exchange Server Prerequisite Check Prerequisite Analysis COMPLETED Configuring Microsoft Exchange Server Organization Preparation FAILED The following error was generated when "$error.Clear(); initialize-ExchangeUniversalGroups -DomainController $RoleDomainController -ActiveDirectorySplitPermissions $Rol eActiveDirectorySplitPermissions " was run: "Microsoft.Exchange.Data.Directory.SuitabilityDirectoryException: An Active Directory error 0x51 occurred whe n trying to check the suitability of server 'DC01.Example.com'. Error: 'Active directory response: The LDAP server is unavailable.' ---> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable. at System.DirectoryServices.Protocols.LdapConnection.Connect() at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCrede ntial) at Microsoft.Exchange.Data.Directory.PooledLdapConnection.BindWithLogging() at Microsoft.Exchange.Data.Directory.PooledLdapConnection.TryBindWithRetry(Int32 maxRetries, ADErrorRecord& errorReco rd) --- End of inner exception stack trace --- at Microsoft.Exchange.Data.Directory.TopologyDiscovery.SuitabilityVerifier.CheckIsServerSuitable(String fqdn, Boolean isGlobalCatalog, NetworkCredential credentials, String& writableNC) at Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, String partit ionFqdn, ADObjectId domain, String serverName, Int32 port, NetworkCredential credential) at Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, String partit ionFqdn, NetworkCredential networkCredential, String serverName, Int32 port) at Microsoft.Exchange.Data.Directory.ADDataSession.GetConnection(String preferredServer, Boolean isWriteOperation, St ring optionalBaseDN, ADObjectId& rootId, ADScope scope) at Microsoft.Exchange.Data.Directory.ADDataSession.GetReadConnection(String preferredServer, String optionalBaseDN, A DObjectId& rootId, ADRawEntry scopeDeteriminingObject, DualSearchMode dualSearchMode) at Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& resp onseControl) at Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextResultCollection() at Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.GetNextPage() at Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.<GetEnumerator>d__0.MoveNext() at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientObjectSession.<FindByAccountName>d__2`1.MoveNext() at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientObjectSession.FindByAccountName[T](String domainName, Strin g accountName) at Microsoft.Exchange.Management.Tasks.InitializeExchangeUniversalGroups.InternalProcessRecord() at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b() at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePip elineIfFailed)". The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.
I looked at a network capture while attempting to run it again and saw something odd. Right at the time of the failure in the ExchangeSetup.log there’s an attempt to contact DC01.example.com a non-GC Domain Controller on port 3268. Which obviously fails.
The problem appears to occur during the execution of the command:
initialize-ExchangeUniversalGroups -DomainController $RoleDomainController -ActiveDirectorySplitPermissions $RoleActiveDirectorySplitPermissions
Looking in the log file it identifies a Preferred GC (DC02) and Preferred DC (DC01 which is the Schema Master). They are used successfully it seems earlier in earlier portions of the update. But when initialize-ExchangeUniversalGroups runs, for some reason it doesn’t use the identified GC, doesn’t even try before attempting a connection to the non-GC.
In trying to fix this, I moved the Schema Master role from DC01 to DC02 (the GC). The next time /PrepareAD worked fine. Presumably making the Schema Master a GC would have also worked. Strange problem though as I’ve done the rest of the schema updates involved in the previous 2013 CUs without any problem.
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.
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.
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.
All domain controllers in the Active Directory domain
Replicates zone data to all domain controllers in the Active Directory 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.
Fantastically useful set of instructions! If only Cisco’s own docs were this good…
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
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.
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!
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