EzETL - Intro

Dump database data to a file. Be it stored in a table or a result of a complex query. Or maybe your data source is a SharePoint list? That's fine too
Load data into database stage tables and then invoke some SQL to massage it and put into the permanent place. No matter what vendor the database comes from
Easy! Copy .NET binaries into a folder; configure connection strings; put together a configuration file in XML format. Test. Easy to read log files and console output are at your disposal. Now, just schedule the batch job with your favorite scheduler. Done.
Control. Your ETL tasks are defined with plain text files only. Use source control like SVN or Git to keep track of your changes
And, it's FREE
It's EzETL

Windows 7: Removing stale sync partnership

If you want to delete a sync partnership you no longer need (if the server went south and will never be back, for instance), you’re in an interesting situation. Windows 7 graphical tool will not allow you to delete a partnership unless it is in an OK state, which is not the situation here. So here’s how to delete it:

• In 'Manage Offline Files' delete temp files ( not sure it's not redundant, but it won't hurt)
• In 'Manage Offline Files', turn offline files off
• Reboot
• Login and navigate to C:\Windows\CSC\v2.0.6\namespace
• Locate the folder named as the server you want to delete. Right-click on it and open Properties->Security
• Click button 'continue', take over the ownership of the folder, including all its children
• Now you can delete the folder
• In 'Manage Offline Files' turn offline files on
• Reboot

A Solaris CIFS Mystery

Ever since I switched to Solaris 11 Express and CIFS, I have had a mysterious issue.  The process would occasionally break when I copied files from CIFS share or when I played music from it. The music would stop, the player would get very confused, and file copy would be interrupted.

This had never happened with Samba. I considered switching back to Samba, but it's kind of obsolete in the Solaris world, and probably not as integrated with ZFS as CIFS.

There was no problem in accessing any other resource over the network. There was also no problem in transferring the very same files from Solaris to my PC over SSH protocol.

I have turned debug on. And in Solaris syslog I could see millions of records like this:

Feb  3 11:53:52 solnas smbsrv: [ID 421734 kern.notice] NOTICE: [SMEL\sergey]: common share not found
Feb  3 11:53:52 solnas last message repeated 58 times

Once I had compared this to similar complaints on the Internet forums, I figured out that ‘common’ is the share name. It’s true that my server has no such share, but why was my laptop constantly trying to retrieve it?

There used to be such a share on my old server. I suspected laptop remembering it. But then another idea came to my head...

The old server was actually still alive (under a different name), since my wife had not migrated her email yet. I went to its smb.config. Lo and behold! The old server announced itself over WINS as one of the DNS aliases of the new server. So I changed the WINS name of the old samba server, and then I even killed the nmbd process on it.  At first it seemed as if that had made a difference – there were no more ‘share not found messages in the log. They appeared again after a while, however.

At that point I had stopped the old Samba altogether and rebooted the laptop, but the messages and file access errors kept coming.

I went on to disable the Windows networking options one by one: Homegroup, Discovery, Topology, File/Print sharing, QoS. None of that did any good. The file access kept breaking and the same messages came up in the Solaris syslog.

Finally, I removed the server’s network alias from the DNS. There was only one network name left for it. This had an immediate effect. Now both the file access errors and message logs are gone. 

Mystery...

Dear Windows 7, how can this be?

C:\Users\sergey>nslookup win7video
Server:  ws2003.smel.local
Address:  192.168.2.221

Name:    win7video.smel.local
Address:  192.168.2.12


C:\Users\sergey>ping win7video

Pinging win7video.smel.local [192.168.2.19] with 32 bytes of data:
Reply from 192.168.2.10: Destination host unreachable.
Reply from 192.168.2.10: Destination host unreachable.

C:\Users\sergey>ping win7video.smel.local

Pinging win7video.smel.local [192.168.2.12] with 32 bytes of data:
Reply from 192.168.2.12: bytes=32 time=1ms TTL=128
Reply from 192.168.2.12: bytes=32 time=2ms TTL=128
Reply from 192.168.2.12: bytes=32 time=1ms TTL=128

If Windows 7 tells that you need to get permission from yourself...

#  /usr/bin/chmod -R A+user:<your uid>:rwxpdDaARWcCos:fd:allow .

ESXi iSCSI initiator and data store

At this point I have an ESXi hypervisor, which is hosting a few important virtual machines from a SSD drive. That is, a Windows 2003 AD server, and Solaris 11 NAS server. NAS server has 4 large drives passed through to it. Solaris 11 organizes these 4 drives into RAID-Z (Stripped, 1 parity disk) ZFS pool. From this pool, NAS server caters to the windows and UNIX clients on the network. I also created an iSCSI target ( or LUN) in the pool, of 500GB.

Now I want to make this LUN available on the ESXi hypervisor itself. ESXi will create a data store on the LUN, where other virtual machines will be stored. Those won't be the machines that are always on, like AD server or NAS server. They will be my lab machines.

In the future I will be able to 'mount' this LUN from another ESXi host, should I need more resources to run these machines. But for now, all iSCSI network traffic will be on the virtual network inside the ESXi host. I want to make the setup simple and inexpensive, so there won't be hardware iSCSI adapters or dedicated network cards or any security between iSCSI initiator (ESXi) and target ( Solaris NAS )

This makes any ESXi networking configuration unnecessary - I will just use the  management network already configured at the installation time.

1. Log in to the vSphere Client, and select a server from the inventory panel.
2. Click the Configuration tab and click Storage Adapters in the Hardware panel.The list of available storage adapters appears.
3. Select the iSCSI initiator to configure and click Properties.
4. Click Configure.
5. To enable the initiator, select Enabled and click OK.

Add static target. I use the IP address of the Solaris 11 NAS virtual machine and the target ID created for me (see the previous post). I use no authentication.

ESXi will offer a rescan, and new LUN shows up

Create new data store on the iSCSI LUN

iSCSI target

Install and enable COMSTAR

# pkg install storage-server

# svcadm enable stmf

Create volume for the target. Size is required.

# zfs create -V 500g tank/iscsi1

Create LUN 

# stmfadm create-lu /dev/zvol/rdsk/tank/iscsi1 

# stmfadm list-lu 
LU Name: 600144F0544C880000004CFF6DFE0001

Publish LUN to all hosts (to make our life easier for now)

# stmfadm add-view 600144F0544C880000004CFF6DFE0001

# stmfadm list-view -l 600144F0544C880000004CFF6DFE0001
View Entry: 0
    Host group   : All
    Target group : All
    LUN          : 0 

Start the service  (ignore the warning)

# svcadm enable -r svc:/network/iscsi/target:default
svcadm: svc:/milestone/network depends on svc:/network/physical, which has multiple instances.

# svcs -l iscsi/target (to test)

Create the target
# itadm create-target
Target iqn.1986-03.com.sun:02:08739864-69d3-cb63-c4be-c1b2b03d83b3 successfully created


# itadm list-target -v (to test)

Creating shares

I already had several shares created for me by Nexenta GUI when I played with it. I had them imported automatically to Solaris machine with their disk pool 'tank' using command

#zpool import -f tank

Now I'm creating an additional file system named 'work' on pool 'tank' manually.

# zfs create -o casesensitivity=mixed -o nbmand=on tank/work

Check if it worked:

#df

...

tank/work 4332676508 44 4332676465 1% /volumes/tank/work

Share it to the Windows clients

# zfs set sharesmb=on tank/work

I could see share 'tank_work' from my Windows machine. But I liked name 'Work' better.

# zfs set sharesmb=name=Work tank/work

Now, it would be nice to write something to this share. One way to grant myself all rights is the old chown command:

# chown sergey /volumes/tank/work/

At this point I could see share Work on my Solaris NAS server and I could create files and folders under it.