"Unable to connect to the MKS" error when using vSphere Client

Had this strange little incident today where three new vmware esxi 4.1 hosts suddenly would not let me see the console for any of the virtual machines from my vSphere client.

I would always get the following error:

"Unable to connect to the MKS: Failed to connect to server myesx.domain.intern:902."

Turns out that the DNS-records in Active Directory were messed up so instead of pointing to the management network interface of my esxi-servers, they were pointing to some dhcp-addresses. It could have happened after fiddling around a bit when setting up a new management network. I presume esxi isn't able to renew ddns registrations (I am after all using static addresses on the management network interface). Anyway a simple static registration of the servers in DNS took care of the problem instantly.

Errors creating ArcSDE repository and authenticating new ArcSDE instances in Post Install

I recently installed the new ArcGIS Server 10 and ArcSDE 10 for SQL Server in a lab environment using a staging license.

The default SDE database (running the esri_sde service on port 5151) was installed without errors, but when I tried setting up a second SDE-enabled database I had some issues that I would like to share.

I used DBO schema to create a single spatial database. I got as far as to the repository setup which told me that “The ArcSDE repository was unsuccessfully completed. Would you like to view this error”. The error turned out to be a blank file so not much info there. However when I tried again I was given the following warning “The geodatabase already exists. If you want to upgrade the geodatabase see the ArcSDE installation guide for instructions”. I had a look at the database and it looked like all the SDE-tables were already created so I decided to proceed.

Next thing up was authorization. I chose to “authorize with ESRI now using the internet” and typed my authorization number. It got as far as “Authorizing software” before it gave me an error: “Unspecified error no valid features found in the received authorization data. Please check the data you entered and try again.”

So I tried again – this time with the option “Authorize at ESRI’s website or by email to receive your authorization file.”. Well I got the file and the same thing happened. Strangely enough the AUTH_KEY value in SDE_Server_config table contained what seemed like valid data so I decided to go ahead and create the service. The service started, always a good sign.

I couldn’t find any more info about this on the net but was able to reproduce the problem together with an ESRI techician, and it turns out the issues are known to happen if you run ArcGIS Server and ArcSDE on the same Windows server. I use this config for now because this is a lab environment so I’m not worried about performance. I guess it’s not pretty, but as long as it still works I’m a happy camper. Hopefully someone else can use this info, because ESRI does not seem to want to publish it on their website. Afterall, a bug is not really a bug until someone notices it. Apparently.

Update: I was just informed by ESRI that this problem will be taken care of in the next Service Pack.

Samsung Vibrant Galaxy S review

Since I recently moved from Europe to the US I had to get a new phone. My brand new HTC Legend did not work with the 3G bands over here. Who would have thunk….  Since the Legend wasn’t available at T-Mobile I decided to go for the Samsung Vibrant Galaxy S instead. All reviews were overwhelmingly positive. I was led to expect that this was the best Android phone per today. Well, after a month’s use I am a little disappointed. I still prefer the slower, smaller and technologically inferior HTC Legend and here’s why:

Pros

The Samsung has a great screen, a really fast CPU and enough RAM to where it will always start your applications quick! It also has a pretty sleek design, although it really looks a lot like a iPhone 3g.

T-Mobile also bundled it with The SIMS and the movie Avatar in great quality.

Cons

Plastic fantastic: Compared to HTC Desire and Legend, or IPhone the Galaxy feels cheap. The plastic is hard and is too easy to scratch.

GUI: The GUI designers did an inconsistent job. For instance when you turn the phone on or off – it will play a loud annoying Jingle. It will even show a horrible animation with ugly pink “Goodbye!”-logos flying around the screen. What were they thinking? Compare that to the slick startup/shutdown of the HTC phones and you’ll know what I mean. I also think the font size is too large for the most part. Personally I like smaller fonts in order to fit more information on the screen. For the most part the GUI is functional enough though, but it is not nearly as nice as Sense or IOS.

Slow GPS: The GPS is ok when it works, but it can be extremely slow. Sometimes it takes 5-10 minutes to get ready.

Several Google Calendars: It simply will not sync several Google Calendars. I have my Google calendar hooked up to my wife’s. She can see my appointments on her Android phone, but I can’t see hers. And we all know how popular it is when you miss appointments that your wife has set up for you.

Music player: I listen to audio books a lot. These usually consist of several CDs. Let’s say I stop listening at 3 mins 30 secons of track 3, CD5. Then I decide to continue the next day. What will happen is that I click the “now playing” button, and it will take me to the beginning og track3, CD5. Then it will skip to track3, CD6 next to track3, CD7 etc. In other words it will start playing from the playlist containing all songs, not the albumlist which I want. Utterly annoying.

Samsung KIES and no tethering: What a horrible horrible bugridden piece of bloatware this is. I tried installing it in order to use phone tethering, but I gave up. It would simply halt my system to a crawl, and it just wasn’t worth it. I ended up buying easytether instead ($9.99 is cheap compared to crippling my main system). In comparison the HTC Legend had tethering working pretty much right out of the box, no need to buy extra software. KIES makes iTunes seem like a walk in the park in comparison. Luckily it’s not needed very often and thank God for that.

No trackball: Sometimes when you’re browsing you just can’t hit that particular checkbox no matter where or how you press the screen. Other times you’re editing text and need to click exactly on a particular letter in a string. This is where a little trackball or optical trackball (which the HTC phones have) comes in handy. The Vibrant does not have this, and thus it can be quite frustrating.

Exchange connector: I’m not sure why they chose this solution, but the email-client for Exchange is not as good as HTC's implementation. The most annoying part is that I cannot move messages between folders. Navigating between folders is also annoying because they are listed partially alphabetically on top of the screen, and you have to scroll sideways until you’re in the right folder. I have about 100 folders in a tree structure, and finding the right folder can take a while.

Conclusion

Most of these shortcomings are software related and can be fixed. It makes a potentially great phone feel like it is a beta product. It just has not been tested enough. The big question is whether Samsung intend to do something about it or not. It remains to be seen I suppose. If not I’m going to go for a HTC next time.

Manual unauthorization of DHCP server in Active Directory

A while ago we moved our DHCP-server to another server, and unfortunately we forgot to unauthorize the old server in the process. Sloppy I know, but it does not seem to have any practical implications. The old server still shows up when I do a "netsh show dhcp servers" or use the DHCP-server MMC plugin. Anyway, I hate mess in Active Directory so I figured I should get rid of it.

Trying to unauthorize it from the DHCP-server MMC plugin would only result in a "there is no such object on the server"-warning and using "netsh dhcp delete server SERVER1 10.0.0.0" did not help either, so I had to do it manually.

First I deleted the old server (SERVER1) from ADSIedit:
CN=NetServices,CN=Services,CN=Configuration,DC=DOMAIN,DC=INTERNAL

then I edited the current (working) DHCP-server object:
CN=DhcpRoot,CN=NetServices,CN=Services,CN=Configuration,DC=DOMAIN,DC=INTERNAL
the "dhcpServers" attribute contained both the old server and the new server, so I deleted the old server from the list.

That seems to have done the trick (I speeded up the process my replicating my AD manually and restarting the dhcp-service).

Windows XP and DHCP relay

An interesting issue occurred today. We have a new subnet (temporarily) set up on one of our Checkpoint Firewall legs.

The subnet has a HP ProCurve 6600 router/switch with another subnet serving a number of Windows XP / Windows 7 clients using DHCP. They all get their IP-Addresses from a internal DHCP server (via DHCP relay (the vlan has "ip helper-address 10.10.5.5" set)).

The network setup is illustrted below:


client net (10.13.0.0/16)
   |
   |
[Procurve 6600 router]
 w/DHCP relay enabled
   |
   |
firewall net (10.14.0.0/16)
   |
   |
[Checkpoint firewall] ------ Internet (99.98.97.18/30)
   |
   |
Server net (10.10.0.0/16)
   |
   |
[DHCP Server 10.10.5.5]


The problem was as follows:
Windows XP clients (and Windows server 2003 it turned out) on the client net were not able to obtain IP-addresess. They would work fine using a static IP-adress, but issuing the commands "ipconfig /release" followed by a "ipconfig /renew" would simply time out and result in a 169.x.x.x address. What's more interesting was that Windows 7 clients worked without a problem.

I tried all the following:
- Opening all Checkpoint firewall ports between the Client Net and the Server Net
- enabling a "permit ip any any" ACL on the 6600 router
- Verifying all routes and ports (esp. UDP 67/68)

Finally I installed good old Microsoft Network monitor on a XP client and ran a trace. The log showed:

{DHCP:0, UDP:2, IPv4:3} 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0xBC62C647

so far so good, the clients sends a broadcast looking for a DHCP server.

{DHCP:0, UDP:2, IPv4:3} 99.98.97.18 10.13.4.97 DHCP DHCP:Reply, MsgType = OFFER, TransactionID = 0xBC62C647

We actually get a reply, but source appears to be the Internet hide-behind (NAT) address of our firewall. The destination address is the one we requested. However - inside the packet the identy of the DHCP server is "ServerIP: 10.10.5.5". I'm not sure whether this is a security mechanism in XP but after turning off NAT so source address matched the ServerIP-identity everything worked like a charm on both Windows XP and Windows 7 clients (see the log):

{DHCP:0, UDP:2, IPv4:1} 0.0.0.0 255.255.255.255 DHCP DHCP:Request, MsgType = DISCOVER, TransactionID = 0xC6A77CFC
{DHCP:0, UDP:2, IPv4:1} 10.10.5.5 255.255.255.255 DHCP DHCP:Reply, MsgType = OFFER, TransactionID = 0xC6A77CFC
{DHCP:0, UDP:2, IPv4:1} 10.10.5.5 255.255.255.255 DHCP DHCP:Reply, MsgType = ACK, TransactionID = 0xC6A77CFC

Windows 2008 terminal server licenses not being assigned to users

We have a Windows 2003 domain and have just set up some new terminal servers using a Windows 2008 terminal server licensing manager server in the domain (per user licensing). This license server is not a DC.

The problem was that most users would not be assigned licenses from the license server and the event viewer on the licensing manager server said the following:

"The Terminal Services license server cannot update the license attributes for user "XXX" in the Active Directory Domain "mydomain.intern". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "mydomain.intern".
If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs."

Well, sure enough the server in question was not member of the "Terminal Server License Servers" group at first but was later added. Then we restarted both the terminal servers and licensing servers but the problem remained.

A little further investigation showed that this problem occured for apx 2/3 of our users. Checking users permissions with powershell:

get-user jdoe |get-adpermission -user s-1-5-32-561 |fl

User : S-1-5-32-561
Identity : mydomain.intern/Users/John Doe
Deny : False
AccessRights : {ReadProperty, WriteProperty}
ExtendedRights :
IsInherited : False
Properties : {Terminal-Server}
ChildObjectTypes :
InheritedObjectType :
InheritanceType : None

revealed that the group "Terminal Server License Servers" is present with some special permissions on the accounts who works. Checking an account that does not work did not list this permission. By the way S-1-5-32-561 refers to the "well known SID" for the group we're looking for:

SID: S-1-5-32-561
Name: BUILTIN\Terminal Server License Servers
Description: An alias. A group for Terminal Server License Servers.

My first thought was that it was inheritance related, but the users OU showed no trace of the "Terminal Server Licensing Servers"-group and looking at the output above clearly says "inheritancetype: none". Interestingly enough all newly created users gets the correct permissions which indicates that the permissions comes as a part of default settings from the AD-Schema. When checking the schema I saw that the "Terminal Server Licensing Servers"-group indeed is present with some kind of permissions on the users object, but the AD Schema MMC-snapin doesnt seem to be able to list which particular permissions this is.

Anyway - at one point a job must have been triggered that tried to set these permissions for all user accounts (?) in my domain, but it must have stopped at one point. I can't really think of any other possibility than that this must have happened during the TS licensing server installation. Can this somehow be trigged manually? Or is there another way to get this done by the book? Google brought me no further.

The obvious and simple workaround was to simply add the permissions manually through powershell and hope for the best, but it still leaves me with a feeling that something is not quite right.

Update:
Thanks to powershell I succeeded in finding a pattern. The following script lists all users where "Terminal Server License Servers" have access rights:

$users = get-user | get-adpermission -user s-1-5-32-561
write-host $users.count
$count = 0
while ($count -lt $users.count)
{
   write-host $count $users[$count].identity
   $count++
}

The users listed had the following in common; they either:
a) were created after we upgraded the domain from windows 2000 to Windows 2003 (SP1)
  or
b) were members of domain admins, account operators or printer operators.

We already know that new accounts receive the correct access right upon creation and admins/operators accounts automatically have their access rights adjusted automatically by Active Directory mechanisms running hourly on the PDC-emulator according to permissions set on System/adminSDholder container in AD (just try adding a user to account operators and notice that account operators access rights to this user account will disappear after a while by itself).

In other words - these permissions have never been applied to all user accounts in the domain. I cannot imagine that this is by design, if it was there would be a lot of MS customers scratching their heads. I suppose our domain is an exception, so I guess I'll just stick to applying the necessary access rights settings by powershell (with the following command).

get-user * | Add-ADPermission -user S-1-5-32-561 -accessrights ReadProperty,Writeproperty -properties Terminal-Server -inheritancetype none 

HP VLS6636 deduplication real world performance

A few months we installed a new virtual tape library - a HP VLS6636. The library and our Data Protector 6.11 backup server are connected through a FC switch, and most server backups are done via regular gigabit ethernet.

Currently the library has 24 x 476(500) GB SATA disks. A total of apx 11 TB raw capacity which after initialization leaves 8.8 TB physical capacity. 1.04 TB is reserved by the system (temp-space for deduplication etc) so the space left for backup data is 7.76 TB.

The total size of all our backup data is apx 3,04 TB with an average of 0,26 TB differential data daily. It's all kinds of data - but mainly Winows Server OS. My goal was to hold 5 weeks of full an ddifferential (Mon-Thu) backups, some manual backups and in addition leave room for some future growth. The rough calculation for our current needs is like this:

Full backup: 5 x 3.04 TB
Differential backup: 4 x 0.26 TB x 5 (4 days a week for 5 weeks)
A total of 15.2 + 5.2 = 20,4 TB
+ 10 TB growth and manual backups

In other words - we require 4 times the available space on the VLS6636. Time to start filling it up :)

The first reading (7.1) is done after two full backups and a few manually defined backups.

The increase in Logical data usage after 4.2 is due to a couple of full backups outside the regular backup schedules, so you're in fact looking at 7 full backup sets.Notice that even though the Logical data increases sharply, there's hardly any increase in used capacity.

After 11.3 you'll notice a sharp increase in the logical data and a decrease in available capacity. This is due to changes in backup procedures for Virtual Servers (VRanger Pro upgrade). Basically the same VM's are being dumped to file, but the dump - and metadata files look different and the VLS6636 naturally interprets it as new data and thus ruining the nice stats. I expect the data usage to go back to what it was prior to 11.3 once backup data from the old VM backup procedures have expired.

This illustrates the importance of remembering things like this when using deduplication technology. Seemingly small changes can have a significant impact on storage needs. This also goes for the backup jobs. Creating two similar jobs with different names will be considered completely different sets and thus they will not deduplicate at all.

All in all; as long as the backup definitions and data are fairly static in terms structure and contents - the deduplication works very well. Even the differential backups deduplicate quite well, I would estimate an average of 5:1.

When it comes to speed the VLS6636 really performs decent. We experience speeds up to 60 MB/sec when using 4 simultanous datastreams. On average mixed backup to VLS will happen at apx 40/MB sec. The backup server is fairly old, so I would not be surprised if the results will be even better with a new backup server.

We have also restored files for verification purposes, and haven't noticed any problems. Yet ;-)

HP BladeSystem C7000 Onboard Administrator lost contact with ILO2 on a Proliant bl460c blade

A while ago we upgraded our HP BladeSystem C7000 Onboard Administrator (OA) firmware to the latest 2.60. A few weeks later we upgraded the ILO2 firmware on the blades to 1.80. All but one worked fine. The last blade would not communicate properly with OA. Nothing serious I suppose, but I'm always suspicious - thinking that small issues could lead to something horrible if not dealt with properly. Plus - it's annoying.

Symptoms:

• I could not initiate a ILO remote control session from the OA web interface (it would time out and say "Unable to perform autologon").
• The only way I could connect to ILO was adding a local user with HP Lights-Out online configuration utility (hponcfg) from Windows running locally on the blade.
• The configured ILO DNS-name would not register with OA.
• OA / Device Bay Summary would report "iLO name: [Acquiring]" and "iLO DVD Status: unknown".
• IML Log for the blade was not available from OA.

I tried all tricks I could think of:

• Ran a emulated eject/insert of the blade ("reset server bay XX" from OA CLI).
• Reset all settings on the ILO card to default from hponcfg.
• Rebooted the ILO card from hponcfg.
• Upgraded ILO2 firmware to 1.81
• Restarted OA.

However - what finally solved it was simple enough. I simply reapplied the 2.60 firmware upgrade again. Fair enough.