AD Integrated DNS Zones Disappearing

Here is a weird issue I ran into last week. Maybe someone who sees this will stumble upon this post and find useful.

If one changes an AD Integrated DNS Zone from Domain based replication to Forest based replication, it actually propagates a "delete" to all other domain controllers before propagating the "new" DNS zone in the alternative AD Application Partition. Here is a sample of what this event looks like in the eventlog on two "test" domain controllers:

Event Type: Information
Event Source: DNS
Event Category: None
Event ID: 713
Date: 11/19/2009
Time: 9:01:23 AM
User: N/A
Computer: TESTDC01
Description:
An administrator has moved the zone test.local to a new location in Active Diretory. The zone will be stored in Active Directory at DC=test.local,cn=MicrosoftDNS,DC=ForestDnsZones,DC=test,DC=local.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Information
Event Source: DNS
Event Category: None
Event ID: 4005
Date: 11/19/2009
Time: 09:06:50 aM
User: N/A
Computer: TESTDC02
Description:
The DNS server received indication that zone test.local was deleted from the Active Directory. Since this zone was an Active Directory integrated zone, it has been deleted from the DNS server.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

In most environments, this will probably be a non-issue. However, if you have high replication intervals, you could see an extended period in remote sites without DNS service.

Also, of note from this testing. You can restore a zone as Domain wide replicated and it will exist in parallel, with no cross-updating, with the Forest based zone. This can add to a real headache when troubleshooting as both domain controllers will appear to have a local copy of the zone with different data..

Just an interesting issue that proved to be the source of a strange event..

Crazy Static NAT Issue

Yesterday I replaced a Cisco Pix 515e (6.3) with an ASA 5510 (7.2). While I am not an expert on Cisco security, I have had to work with these devices quite a bit over the last few years, so I attempted to port as much of the existing configuration as possible to the new device and then attempted a cold cut over. I took down the old device and cabled up the new device and was presently surprised with the site-to-site VPN tunnels came back up and after a small tweak, client VPN worked again as well. To my dismay, there were static NAT statements that published a few inside network interfaces as outside public IP addresses. If time would have allowed, I would prefer to create a proper DMZ and migrate these services off of the LAN, but I digress... After testing everything else (Websense, Etc) it became clear that none of the NAT'd servers could get our and traffic could not come in. I probably spent an hour to 90 minutes looking at all of the ACLs and NAT statements. Finally, I thought about ARP cache. Perhaps, just maybe the Internet Router (AT&T provided 3800) was caching all of the other IPs used for static NAT as the old Pix's MAC Address and the ASA was not ARPing them? A reboot to the 3800 and all of a sudden, SMTP was coming in, the web site was up, all was good with the world again. Talk about a frustrating afternoon, always remember, if at first it doesn't work, reboot everything involved.. :P

Generic AD Scripting

Here is a good way to find your current domain's LDAP path without hard coding it in your script. This is handy if you write scripts to do AD reporting and simply want them to run against the current domain wihtout updating your LDAP strings in your code.



Set rootDSE = GetObject(ldap://RootDSE/)
DomainContainer = rootDSE.Get("defaultNamingContext")
If Instr(DomainContainer, ",") then
arLDAPPath = Split(DomainContainer, ",")
strDomain = Replace(arLDAPPath(0),"DC=","")
End If



This is useful if you want to do something like this: (A SUB that when called writes a CSV with active account info)



Sub GetEnabledUsers(DomainContainer, strDomain)

set objOut = objFSO.CreateTextFile("EnabledUsers_" & strDomain & ".csv")
Set objConnection = CreateObject("ADODB.Connection")
objConnection.Open "Provider=ADsDSOObject;"
Set objCommand = CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.Properties("Page Size") = 1000

objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE objCommand.CommandText = _
";(objectCategory=User)" & _ ";displayname,sAMAccountname,mail,userAccountControl;subtree"

Set objRecordSet = objCommand.Execute
objOut.writeline """" & "Name" & """" & "," & """" & "UserID" &_
"""" & "," & """" & "Email Address" & """"
intCounter = 0
Do Until objRecordset.EOF
intUAC=objRecordset.Fields("userAccountControl")
If intUAC AND 2 Then
'Ignore
Else
objOut.writeline """" & objRecordset.Fields("displayname") & """" &_
"," &_ """" & objRecordset.Fields("sAMAccountname") & """" &_
"," & """" & objRecordset.Fields("mail") & """"
intCounter = intCounter + 1
End If

objRecordset.MoveNext
Loop


objOut.close
WScript.Echo VbCrLf & "A total of " & intCounter & " accounts"
objConnection.Close
End Sub

Migrating Blackberry Enterprise Server (BES) to a VM in parallel

So, the BES I inherited was running on an old server that was ready for a new purpose. I had a nice new Hyper-V based VM ready to host BES services, but there were a couple steps I had to take to get the services there. I was not wanting to make a knife-edge switch, as I wanted to do this a few users at a time. I only have one SRP Identifier, and my support is currently through Sprint, not RIM. Here is the solution I came up with that worked out quite well.

1. Move the database (optional)
The BES was using MSDE on the local server. Since I was decommissioning the local server, this had to move. I migrated from MSDE to an existing SQL 2005 DB. Here is an article for reference: KB12247 on http://www.blackberry.com/btsc/microsites/microsite.do

2. Register with Blackberry/RIM for a trial BES license
You have to sign up and give them a valid email address, but once approved, you get a trial SRP ID. This is required if you want to run your new BES in parallel with the existing BES. As of the time of this posting, you can request a trial here: http://na.blackberry.com/eng/services/server/offers.jsp

3. Load your new BES, use the production DB and Trial SRP
Build the new BES (it should be in the ballpark of your production version). You should be able to point the new BES to your shared DB and manage it alongside your existing BES. Make sure you use the new SRP-ID so that you don't lock your existing SRP. Having these in parallel allows for a much easier migration.

4. Move users
Right-click, move user (you can highlight multiple users if you want to do batches). This will do a seamless OTA migration of the user. You should look at the last contact on the device though, because if it can't find them, your new BES will log an error quite frequently as it attempts to contact and migrate the device.

5. Decommission old BES
Uninstall/Disable services. Remove from Management GUI.

6. Replace temporary SRP with production SRP using Management GUI.
Now you can go back to your original SRP. You are now running on the new server.

This process worked for me. Let me know your experiences.

What a year!

So, I haven't blogged much. It's strange because if you know me, you know I talk a LOT. I've seen a lot this year, as leaving Cheniere proved more difficult that I could have imagined. After a couple brief stops I think I have a home again for a while. That said, I am starting my New Years resolution early. I promise to blog more. I'm in an interesting position (again) at a company that has a lot of opportunity for me. We need an upgrade on storage, networking, management tools, etc. I will recount some of my adventures here in the hopes that others will stumble upon my ramblings and find help or at least consolation that they are not alone!

Here's to 2008, a year that we would all like to forget!
Good bye Ike, Foreclosures, Bailouts, $144 Oil, $40 Oil, Writer's Strikes..

Bring on 2009!