Tag Archives: windows

Can’t join CIFS Server to domain – sasl protocol violation

I was running a live disaster recovery test of our Celerra CIFS Server environment last week and I was not able to get the CIFS servers to join the replica of the domain controller on the DR network.  I would get the error ‘Sasl protocol violation’ on every attempt to join the domain.

We have two interfaces configured on the data mover, one connects to production and one connects to the DR private network.  The default route on the Celerra points to the DR network and we have static routes configured for each of our remote sites in production to allow replication traffic to pass through.  Everything on the network side checked out, I could ping DC’s and DNS servers, and NTP was configured to a DR network time server and was working.

I was able to ping the DNS Server and the domain controller:

[nasadmin@datamover1 ~]$ server_ping server_2
server_2 : is alive, time= 0 ms
[nasadmin@datamover1 ~]$ server_ping server_2
server_2 : is alive, time= 3 ms

When I tried to join the CIFS Server to the domain I would get this error:

[nasadmin@datamover1 ~]$ server_cifs prod_vdm_01 -Join compname=fileserver01,domain=company.net,admin=myadminaccount -option reuse prod_vdm_01 : Enter Password:********* Error 13157007706: prod_vdm_01 : DomainJoin::connect:: Unable to connect to the LDAP service on Domain Controller ‘domaincontroller.company.net’ (@ for compname ‘fileserver01’. Result code is ‘Sasl protocol violation’. Error message is Sasl protocol violation.

I also saw this error messages during earlier tests:

Error 13157007708: prod_vdm_01 : DomainJoin::setAccountPassword:: Unable to set account password on Domain Controller ‘domaincontroller.company.net’ for compname ‘fileserver01’. Kerberos gssError is ‘Miscellaneous failure. Cannot contact any KDC for requested realm. ‘. Error message is d0000,-1765328228.

I noticed these error messages in the server log:

2012-06-21 07:03:00: KERBEROS: 3: acquire_accept_cred: Failed to get keytab entry for principal host/fileserver01.company.net@COMPANY.NET – error No principal in keytab matches desired name (39756033) 2012-06-21 07:03:00: SMB: 3: SSXAK=LOGON_FAILURE Client=x.x.x.x origin=510 stat=0x0,39756033 2012-06-21 07:03:42: KERBEROS: 5: Warning: send_as_request: Realm COMPANY.NET – KDC X.X.X.X returned error: Clients credentials have been revoked (18)

The final resolution to the problem was to reboot the data mover. EMC determined that the issue was because the kerberos keytab entry for the CIFS server was no longer valid. It could be caused by corruption or because the the machine account password expired. A reboot of the data mover causes the kerberos keytab and SPN credentials to be resubmitted, thus resolving the problem.

EMC World 2012 – Thoughts on preparing for a VDI deployment

We’re in the process of testing the deployment of VDI now so I attended a session about preparing for a deployment.   As I mentioned in my previous post, I’m not an expert on any subject after attending a one hour session, but I thought I’d share my thoughts.

The most important take away from the session was mentioned near the beginning – for a truly successful deployment you must do a detailed desktop IO analysis.  It’s important to have a firm grasp on the amount of desktop IO that your company requires and a detailed analysis is the only way to gather that info.   There are “rules of thumb” that can be followed ( 5 IOPs for light users, 10 IOPs for medium users, and 20 IOPs for heavy users), but you could easily end up either over-allocating or under-allocating without knowing the actual numbers.  Lakeside software and Liquidware labs were mentioned as vendors who provide software that does such an an analysis, however I’ve never heard of either of them and can provide no information or feedback on their services. There’s a good free VDI calculator available at http://myvirtualcloud.net/?page_id=1076.  Once you have a good grasp of the amount of IO you’ll need to support, scaling for the 95% percentile should be your target.

What’s the best way to prepare for VDI on a VNX array?  If you conclude from your analysis that your desktop environment is more read intensive, consider hosting it on storage pools that utilize FAST VP with EFD and FastCache.  Using VMWare’s View Storage Accelerator and EMC’s VFCache would also be of great benefit.  If your environment is more write intensive, focus on increasing the spindle count (even at the expense of wasted capacity).  All of the other items mentioned for read intensive environments still apply and would be beneficial.

Final thoughts:

– If you’re using Windows XP make sure disk alignment is set correctly.  If it’s not, you could see up to a 50% penalty in performance.

– Image optimization is very important.  Remove all unneeded services.

– Schedule your normal maintenance operations off hours.  Running patches and updates during business hours could cause the help desk phones to light up.

– Using NFS vs. block is a wash performance wise.  NFS is currently better for scaling up, however, as it allows for up to a 32 node cluster vs. only 8 for block (on linked clones).

– Desktops tend to be write heavy.  FAST VP is great!

Filesystem Alignment

You’re likely to have seen the filesystem alignment check fail on most, if not all, of the EMC HEAT reports that you run on your windows 2003 servers.  The starting offset for partition 1 should optimally be a multiple of 128 sectors.  So, how do you fix this problem, and what does it mean?

If you align the partition to 128 blocks (or 64KB as each block is 512bytes) then you don’t cross a track boundary and thereby issue the minimum number of IOs.   Issuing the minimum number of IOs sounds good, right? 🙂

Because NTFS reserves 31.5 KB of signature space, if a LUN has an element size of 64 KB with the default alignment offset of 0 (both are default Navisphere settings), a 64 KB write to that LUN would result in a disk crossing even though it would seem to fit perfectly on
the disk.  A disk crossing can also be referred to as a split IO because the read or write must be split into two or more segments. In this case, 32.5 KB would be written to the first disk and 31.5 KB would be written to the following disk, because the beginning of the stripe is offset by 31.5 KB of signature space. This problem can be avoided by providing the correct alignment offset.  Each alignment offset value represents one block.  Therefore, EMC recommends setting the alignment offset value to 63, because 63 times 512 bytes is 31.5 KB.

Checking your offset:

1. Launch System Information in windows (msinfo32.exe)

2. Select Components -> Storage -> Disks.

3. Scroll to the bottom and you will see the partition starting offset information.  This number needs to be perfectly divisible by 4096, if it’s not then your partition is not properly aligned.

Correcting your starting offset:

Launch diskpart:


DISKPART> list disk

Two disks should be listed

DISKPART> select disk 1

This selects the second disk drive

DISKPART> list partitions

This step should give a message “There are no partitions on this disk to show”.  This confirms a blank disk.

DISKPART> create partition primary align=64

That’s it.  You now have a perfectly aligned disk.