Xserve and Vtrack Visio stencils, free!

I find it strange that after an hour or so searching the internet... no one has free Apple Xserve and Promise Vtrack Visio stencils.  I needed them for a diagram at work, so I commisioned thier creation.... and I would like to release them to the world!  http://www.mediafire.com/?wn61le8um0iqjty is where you can find them.  It has the front and back of both a Promise Vtrack, and an Apple Mac Xserve G5.  (You know, the servers they quick making because they don't give a damn about the enterprise market anymore.)  Please feel free to copy them and distribute, just please let them remain free.  (Dare I say, open source?)  Credits for actual creation go to Tatso, he is far handier in Visio than I am.

--AR

It's always the simple things that cause the most trouble, March 2011 Edition.

I have been trying to hunt down a "random reboot" problem for a few days now, and I hope that I have fixed it.  I searched all over the internets trying to find folks with similar problems, but to no working solution.

(for those interested in the technical details, I have a multi-node Hyper-V "highly available" cluster running 2008 R2.  For my servers, these are Dell Poweredge R815s with four 12-core AMD processors and Broadcomm 5709C Nics.  I have an Equalogic 6000E and 6500XV for central storage, and I am using iSCSI for all of those connections.)

So the Internets took me to many great sites with complicated fixes, and of course fixes that don't apply to my setup (it seems that Intel has a nasty bug with their processors right now, btw).  For some examples:
http://en.community.dell.com/support-forums/servers/f/956/p/19309520/19608235.aspx
http://blog.mpecsinc.ca/2010/02/windows-server-2008-r2-with-hyper-v.html
http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Windows_Server_2008/Q_26651719.html
 http://social.technet.microsoft.com/Forums/en/windowsserver2008r2general/thread/281d43e9-5f42-45c5-9c90-692de8ba27a4
http://boardreader.com/thread/Random_Reboots_with_a_R710_and_Windows_2_rokvXbhvbk.html

In a nutshell, everyone above suggests driver updates, firmware updates, windows updates... all stuff that is pretty simple. The more I Googled, the more I though it might be related to a NIC issue, or at least I had a hunch that it was.

So I decided to take what I call the "dummy" approach.  I went through every NIC, setting by setting on each node in the cluster.  I had already turned off the "Allow the computer to turn off this device to save power" option on the iSCSI nics, but I had left it alone on the motherboard NICS.  I decided to change this so every NIC was the same, disabling the setting.

Then a meeting took me away from diagnosing it any further yesterday... I went home, expecting to get a bizzilan e-mails from SCOM the next morning, as one or more nodes reboot at night.  But my inbox was free of SCOM's nagging, and none of the nodes rebooted.  So no matter how many times we forget, we should check the simple things first.

--Bryan

Why Apple will never be an enterprise player.

Apple is kind of like the rich kid in high school who was an asshole, but everyone liked him because he had money.  I try to like Apple and their products, but the more I get to know them, the less I like them.  Besides the censorship and their situation with Adobe on their mobile devices, anytime I have to deal with their "enterprise technology" I am disappointed at the little things that break.  Yesterday was one of those days....

I have had an issue for several months now where when a PC connects to an SMB share on my OSX 10.6 server, it behaves strangely.  I can upload any file I want of any size I want to the Apple server, but when I try to pull the file down it errors out saying, "file is no longer accessible."  Another weird part is it gets extremely close to being done before it fails.  (For example, with a 6G file, it was within 20mb of completing, and with a 28k file, it copied more than 26k of it.)

I spent many, many hours Googling for a solution over the span of 6 months.  (Using USB drives for the rare occasion that files had to be transferred... and used sneaker-net to move them.)  Most of the solutions I found on forums blamed the PC and FAT file systems... you could tell they were written by mac-fanboys who don't have any idea about what they are talking about.  But enough about that rant, let me give you the answer.

It turns out that Samba was the problem.  So after reading about how the version of SMB that is distributed with OSX is way old, I started investigating how to up grade Samba to the latest edition (oh, btw, you use MACPORTS for that).  While I was waiting for the 8.9G of Apple developer tools to install so I could install MACPORTS, I by chance found another article or two:
http://discussions.apple.com/message.jspa?messageID=10532382
http://support.apple.com/kb/TS3179


ARE YOU FUCKING KIDDING ME APPLE?!?  You (YET AGAIN) release an update to something for your "enterprise-level" applications and FORGET TO TEST IT WITH SOMETHING AS SIMPLE AS SAMBA?  Not only that, but YOU CAN'T WRITE A DAMN SCRIPT TO FIX THE PROBLEM WHEN YOU FIND IT?

So it turns out that Samba shares "all" of the file, including the "Extended Attributes" that are specific to the XSAN file system.  Windows gets the file from the server, then when it receives the EA part it doesn't know what to do with them (as EA is not a Windows kind of thing) and discards the file with an error.  I made the change described in the KB article above and everything works fine now. (the solution is to change "stream support = yes" to "stream support = no" in /etc/smb.conf) .

So... I hope this post finds someone someday who might have the same problem that I did and may come across this post that might perhaps save a bit of their sanity.

Thanks internet for letting me rant.....

--

And now for some terms that I used to try to find this problem that may help this article be found by someone in need:

XSAN
the item can't be found
file disappear after copy
SMB mac
samba mac
OSX
XSERVE
mac windows compatibility
stream support = no
extended attributes
xsan and samba
xsan and smb
file copy to pc almost completes
file copy from xserve almost completes
Apple file sharing problem
apple file sharing issue
file size issue with SMB
file size issue with samba
smb connection issue
samba connection issue
windows osx samba
windows pull file from xsan
Problem connecting to my Windows (SMB) share in 10.6

Macs, Windows 7, and SMB shares

I was recently creating a SMB share on one of my Mac 10.6 servers that acted funny.  It would keep asking me to log in, even though I had the correct credentials.  I accidentally discovered that a Windows 2008 R1 machine could hit it just fine... but my Windows 7 box could not.  This lead to a search of the internets, and I discovered a somewhat-related problem (it was actually crashing Samba on the server side)...  Someone on that blog wrote that it has to do with NTLM.  I figure the security permissions were changed from Windows 2008 R1 to R2, and also between Vista and Windows 7.  The post mentions to change a bunch of stuff in the "local security policy" of the Windows box to make it work.  I don't like changing a whole lot of security stuff, especially loosing it... so here is all I changed to make this work , citing "nikonz" from the site above for the original fix (with my changes):

"Control Panel --> Administrative Tools --> Local Security Policy

Local Policies --> Security Options

Network security: LAN Manager authentication level
Send LM & NTLM responses - use NTLMv2 session security if negotiated"

There, once again my Macs and PCs are at peace with each other again.

3 hours = worlds longest command line

This was on one line, thought I would share it with everyone:

msdeploy -verb:sync -source:"metakey=lm/w3svc/571459,computername=server1" -dest:"metakey=lm/w3svc/2989,computername=server2" -skip:"objectName=metaProperty,attributes.name=LogFileDirectory" -skip:"objectName=metaProperty,attributes.name=SSLStoreName" -skip:"objectName=metaProperty,attributes.name=SSLCertHash" -skip:"objectName=metaProperty,attributes.name=SSLStoreName" -skip:"objectName=metaProperty,attributes.name=ServerBindings" -skip:"objectName=metaKey,attributes.path=blahTOBlah" -skip:"objectName=metaKey,attributes.path=HTTPtoHTPPS" -skip:"objectName=metaKey,attributes.path=redirectToBLAH" -skip:"objectName=metaProperty,attributes.name=AppFriendlyName" -skip:"objectName=metaProperty,attributes.name=SecureBindings" -skip:skipAction=delete -replace:"objectName=metaProperty,match=m:\websitelocation1,replace=x:\websitelocation1" -replace:"objectName=metaProperty,targetAttributeName=value,match=apppool2\.0,replace=apppool" -replace:"objectName=dirPath,match=m:\website1,replace=x:\website" -enableLink:AppPool -disableLink:ContentExtension -whatif > msdeploysync.log



Ouch.
--Bryan

Microsoft finally follows it's own RFC... now stuff is broken.

We have a web service that goes out and talks to other web services. Our web service and the other ones are protected by firewalls, as we don't want just anyone hitting our web services. As we move to windows 2008 r2, we noticed something funny was happening..... our connections were being blocked.
Turns out that Microsoft is finally following their own RFC and it is breaking things.  Windows servers now will use the "IP address most closely matching the gateway" to decide what IP address to use as the default one.  So now our webservice was using the "lowest" ip address we had, which was for a site that had nothing to do with the webservice.
I found out I wasn't alone being surprised by this new "feature" and found that there is a workaround.
In short, you need to:
-Download and apply the hofix. (the MS extractor was currupt, so I used 7zip to extract the files)
-Reboot for the hotfix to take effect.
-Gather a list of all your IP addresses on that machine, take out the one you want to be the "default IP." Put them in the variable $currentIPs.  Then you can run the script as below, it will remove and add the IPs all at once with little downtime.

I forgot to remote desktop using the FQDN, so I was disconnected, but when I reconnected everything was happy.

$currentIps = "10.1.1.1","10.1.1.2","10.1.1.3","10.1.1.4"


foreach ($ip in $currentIps){

netsh interface ip delete address public $ip
write-host "$ip deleted"
netsh interface ip add address "public" $ip 255.255.255.0 skipassource=true
write-host "$ip added"
}
Write-Host "I suggest you reboot your server now, just in case."

Notice the "skipassource=true."  This will not work before the hotfix.  Again you do not want to run that parameter with your IP address that you DO want to be the default one.
(My Subnet mask is 255.255.255.0, if yours is different, then change it above.)

Windows Auditing can be annoying. (Shut up already)

My audit logs were filling up with a bunch of B.S. from perfectly good packets being successfully sent and received. (event id 5157, and 5152) By default, Windows thinks you want all of these packets logged... and perhaps some admins do. But they can be logged in the firewall log, I don't want them in the event log too. (Default location of the Windows Firewall log is at "C:\Windows\system32\LogFiles\Firewall\pfirewall.log") So after a bunch of googleing, I found several answers that almost worked. Here is what really worked for me on Windows 2008 R2 and R1:


auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable

auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:disable

So there you go, save some audit log space for something that matters, like non-firewall stuff.
-Bryan

(oh, and one more thing, if you want to create a Group policy for this, it is under
computer configuration --> policies --> windows settings --> security settings --> advanced audit policy configuration --> audit policies --> object access. Then double click "Audit Filtering Platform Connection" and check only the box next to "configure the following audit events." DO NOT CLICK THE OTHER TWO BOXES. Repeat for "Audit Filtering Platform Packet Drop" too. If this does not work, edit your GPO to include the policy outlined in Method 1, steps 2 and 3 from http://support.microsoft.com/kb/921468 .  REMEMBER, THE GPO MIGHT TAKE SOME TIME, so if you don't reboot, give it at least 90 min before you give up on the GPO idea.)