One of the things I have always disliked about administering Windows servers and workstations is their inherent inability to act as a basic terminal. You’ve got to use terminal emulation software to login to NFS based firmware and appliances. Recently this became a huge issue when we were required to delete the contents of a volume on a NetApp SAN at Dillon Supply. Here was the scenario:
We have a volume vol0/dscsql2db on a NetApp FAS270 filer. Every night all of the NetApp “snapshots” on this volume need to be deleted. The snap delete command native to the snapdrive service on Windows 2003 servers cannot perform the force deletion of an entire volume. The snap delete command in the OS of the filer can delete the entire contents of a volume regardless of a snapshots state or condition. More specifically, one of the snapshots we wanted to delete is mounted as a read/writable volume on a server (busy, LUNs). Therefore the arguments available in the snap delete command on the filer are required.
So we needed a way to log on directly to the NetApp filer from within a Microsoft SQL DTS (Data Transformation Service) and execute the snap delete command to remove the entire contents of the volume. Basically, I needed to run a Vbscript as a job executed by a DTS against the Netapp filer. That’s where VanDyke CRT came in. I could have used custom expect scripts and spent a long time figuring out how to get them to run through Telnet. Instead we set up a default Telnet session for the CRT application to use when called by the parent DTS (by IP Address) then it automatically executes the following login script:
#$language = “VBScript”
#$interface = “1.0”
Sub main
‘ turn on synchronous mode so we don’t miss any data
crt.Screen.Synchronous = True
‘ Wait for a string that looks like “login: ” or “Login: ”
crt.Screen.WaitForString “ogin: ”
‘ Send your username followed by a carriage return
crt.Screen.Send “root” & vbCr
‘ Wait for a tring that looks like “password: ” or “Password: ”
crt.Screen.WaitForString “assword:”
‘ Send your password followed by a carriage return
crt.Screen.Send “ya, you wish” & vbCr
crt.Screen.WaitForString “etapp1”
‘ ++++ Begin Production commands to delete snapshots
crt.Screen.Send “snap delete -a -f -q dscsql2db” & vbCr
crt.Screen.WaitForString “etapp1”
crt.Screen.Send “snap delete -a -f -q dscsql2logs” & vbCr
‘ ++++ End Production commands to delete snapshots
‘ turn off synchronous mode to restore normal input processing
crt.Screen.Synchronous = False
‘ This will wait 30 seconds
crt.Sleep 30000
‘ dismiss the app
crt.quit
End Sub
Notice the crt.whatever.wait and .send vb scripting objects. It’s these objects included in CRT that made this all possible. Once the script command executes to delete the contents of the volume on the NetApp filer, it closes CRT and our SQL DTS can proceed with creating a new snapshot of our production database volume, mounting this snapshot to a remote server where it is then attached to MS SQL as one of the last steps. Bang! The refreshed reporting server is on-line.
None of this would have been possible without our $35 copy of CRT.
Um, Todd. You should have asked me about this. 🙂
c:\rsh filername snap delete volname snapname
Yes, I should have. I will be changing this. Looks like I was wrong to say this would not have been possible without the copy of CRT.
It looks like I’ll need to load the Rshsvc.exe service from the 2003 Resource Kit. Unless it’s already included in 2003 server unlike XP and 2000 server.