O R G A N I C / F E R T I L I Z E R: 09.12

Sep 14, 2012

problem encountered using ftp-ssl with opalis (and corrected)

for a few days, i have been intermittently pulling my hair out trying to figure out why ftp-ssl with the opalis “upload file” object wasn’t working. after trying many permutations, i finally figured it out. sigh.

it required some opening ports and other stuff… but the last thing that got me was this particular setting which i’ll get to in a second. for now, let’s examine the error in the output:

Error Summary: Connection to FTP site failed
Details:
OPR-FTP(9560) v3.6.17.8 SCRIPT LOG FILE
 
Thu Sep 13 08:46:52 -- Line 6:     FTPLOGON "myftpsite" /user=xxxxxxxx /pw=************** /port=xxx /servertype=FTPSDATA /trust=ALL /timeout=30
Thu Sep 13 08:46:52             => *Logging on to <myftpsite> as SSL/FTP with secure control and data channels.
Thu Sep 13 08:46:52             => *Logon in progress...
Thu Sep 13 08:47:07             => *Change directory (CWD) failed during log on -- may need to use /allowerrors option.
Thu Sep 13 08:47:08             => *Connection to FTP site failed. [1152]
Thu Sep 13 08:47:08 -- Line 7:     IFERROR goto errorexit
Thu Sep 13 08:47:08 -- Line 14:    :errorexit
Thu Sep 13 08:47:09 -- Line 15:    LOGMSG "Error executing FTP script"
Thu Sep 13 08:47:09             => Error executing FTP script
Thu Sep 13 08:47:09 -- Line 16:    EXIT
Thu Sep 13 08:47:09             => *Exit OPR-FTP.
<** CLOSED SCRIPT LOG FILE

 

from the way this looks, during the CWD command, something failed around the log on process. this is what threw me. had i been smart enough to turn on trace logging at this point, i would have spent much less time trying to figure this out. as it were, i went through every permutation i could think of trying to figure out the magic combination. after many cycles of dumb, i discovered tracing was an option (not in the manual) and turned it on.

tracing the error revealed the following (truncated):

ReadServerResponse::read 47 bytes: 250 CWD successful. "/" is current directory.
ReadServerResponse::read 46 bytes: 150 Opening data channel for directory list.
ReadServerResponse::read 33 bytes: 425 Can't open data connection.

 

so as you can see, the misleading error indicated it was in the log on process when in actuality, the log on worked fine. now i knew i could stop screwing around with security and test some of the other options and stumbled upon the one that worked.

image

 

once again, if you look at the trace logs, it shows it here (truncated again):

ReadServerResponse::read 47 bytes: 250 CWD successful. "/" is current directory.
ReadServerResponse::read 52 bytes: 227 Entering Passive Mode (216,133,255,186,254,27)
ReadServerResponse::read 25 bytes: 150 Connection accepted
ReadServerResponse::read 17 bytes: 226 Transfer OK
ReadServerResponse::read 19 bytes: 200 Type set to A
ReadServerResponse::read 17 bytes: 226 Transfer OK

Sep 13, 2012

retrieving wmi class mof information

this powershell powertip is SO cool i just had to repeat it.

using the wmiclass type accelerator, you can use a method called gettext to pull down the mof. so using their example, the following command is issued:

([wmiclass]"win32_pingstatus").GetText("MOF")

 

from that, we receive the following information:

[dynamic: ToInstance, provider("WMIPingProvider"): ToInstance]
class Win32_PingStatus
{
    [read: ToSubClass, key] String Address;
    [read: ToSubClass, key] uint32 TimeToLive = 80;
    [read: ToSubClass, key] uint32 Timeout = 4000;
    [read: ToSubClass, key] uint32 BufferSize = 32;
    [read: ToSubClass, key] boolean NoFragmentation = FALSE;
    [read: ToSubClass, key] uint32 TypeofService = 0;
    [read: ToSubClass, key] uint32 RecordRoute = 0;
    [read: ToSubClass, key] uint32 TimestampRoute = 0;
    [read: ToSubClass, key, ValueMap{"0", "1", "2"}: ToSubClass] uint32 SourceRouteType = 0;
    [read: ToSubClass, key] String SourceRoute = "";
    [read: ToSubClass, key] boolean ResolveAddressNames = FALSE;
    [read: ToSubClass, ValueMap{"0", "11001", "11002", "11003", "11004", "11005", "11006", "11007", "11008", "11009", "11010", "11011", "11012"
, "11013", "11014", "11015", "11016", "11017", "11018", "11032", "11050"}: ToSubClass] uint32 StatusCode;
    [read: ToSubClass] uint32 ResponseTime;
    [read: ToSubClass] uint32 ResponseTimeToLive;
    [read: ToSubClass] boolean ReplyInconsistency;
    [read: ToSubClass] uint32 ReplySize;
    [read: ToSubClass] String RouteRecord[];
    [read: ToSubClass] String RouteRecordResolved[];
    [read: ToSubClass] uint32 TimeStampRecord[];
    [read: ToSubClass] string TimeStampRecordAddress[];
    [read: ToSubClass] string TimeStampRecordAddressResolved[];
    [read: ToSubClass, MaxLen(4096): ToSubClass] String ProtocolAddress = "";
    [read: ToSubClass, MaxLen(4096): ToSubClass] String ProtocolAddressResolved = "";
    [read: ToSubClass, ValueMap{"0", ".."}: ToSubClass] uint32 PrimaryAddressResolutionStatus;
};

 

how cool is that?! thanks scripting guy (ed)! btw, here’s his article.

Sep 4, 2012

finding the right nic in server core

a recently deployed server, on windows 2008 server core, start kicking out some replication notifications which when checking the configuration did not seem to jive. i started poking around when i realized the horror: i don’t know where to find what i’m looking for!

long story short, the server suffered from a biological procedural failure to set the nic properly to the right speed. while the nic was set for auto, it was not set for the critical 1gb full auto. the question now is how was this determined, even though netsh is not helpful for this scenario? the answer is … the registry. <sigh>

 

finding the right interface guid

this is a fairly simple and probably routine thing for you if you’ve done any digging around. the idea is to find the nic with the right ip address associated to it. it’s difficult sometimes to do this when you have a server with four nics but only one enabled. this is a smart way to filter them out.

  • navigate to hklm\system\currentcontrolset\services\tcpip\parameters\interfaces.
  • under interfaces, you should find a set of guids which probably looking something like this example: {FD15E5DE-C7D1-4443-9045-3B1E0A884D0F}.
  • either open each one and look at the ipaddress value or just search at the root of services for the ip address.

image

  • when you have found the correct entry, copy the key name. (yes, copy the long guid :( … just right-click and copy key name then grab the guid)

 

finding the right nic to modify

now that you have the right interface guid, it’s time to find the right nic and poke around at setting the link speed correctly.

  • navigate to hklm\system\currentcontrolset\class.
  • there’s only one guid you need to look for here: {4D36E968-E325-11CE-BFC1-08002BE10318}. there’s probably lots of them.
  • search for the interface guid you found above. i would strongly recommend the “search” method i mentioned earlier, starting from the root of class.

you should find yourself at the appropriate area of the registry. most likely, you will see multiple keys named 0000 through something like 0006*. notice the guid you were looking for is the netcfginstanceid? now you’re in the right place to do yet more digging. :(

image

* or however many keys it takes to store the configuration per interface.

 

finding the right value for speedduplex

i mentioned earlier the server had the wrong setting. i was referring to the speed/duplex seen as *speedduplex in the registry. great. how do i know what to set that to? simple. you find the reference table.

  • navigate to hklm\system\currentcontrolset\control\class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0002\ndi\params\*speedduplex\enum.*
  • find the entry with the right description.
  • the name of the entry is the value to set for speed/duplex.

* the 0002 indicates that it might be a different interface number. remember, there’s one for every network configuration stored. yours might be 0003 or 0005 or whatever.

image

 

setting the speedduplex value

now that you have the right value, set the thing and go… :)

  • navigate to hklm\system\currentcontrolset\control\class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0002.
  • locate the value named *speedduplex and change the value to the value you located in the reference table above.

image

obviously you can use this for other settings as well. :) hope that helps.

 

references

http://blogs.technet.com/b/networking/archive/2009/01/08/configuring-advanced-network-card-settings-in-windows-server-2008-server-core.aspx

http://www.pctools.com/guides/registry/detail/269/