LiquidObject

Large exchange distribution automation

Exchange distribution groups are a very useful method for delivering email to a large number of clients, however every design has it’s limits. I needed to use a distribution list for a rotating number of users with a total count of close to 20,000 members. When looking at distribution groups with more than a few thousand entries causes scalability limits. Naturally I’d rather not have to manually load lists every night.

if(Get-Module -Name ActiveDirectory){}
else{Import-Module ActiveDirectory}

Write-Host "Loading employees"
$myusers = Get-ADUser -filter "*" -SearchBase "OU=Employees,DC=liquidobject,DC=com" -properties description | Select-Object samaccountname
Write-Host "Successfully loaded" $myusers.count "employee accounts."

$alpha = "a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"
foreach($i in $alpha)
{
    $mygroup = "EmployeeSub_$i"
    $myoldgroupmembers = Get-AdGroupMember -identity $mygroup | Select-Object SamAccountName
    Write-Host "Group:" $mygroup "has" $myoldgroupmembers.count "members"
    $mycurrentusers = $myusers | where {$_.samaccountname -like "$i*"}
    Write-Host "We currently have" $mycurrentusers.count "which should be in this group"
    
    $mydiff =  Compare-Object -ReferenceObject $myoldgroupmembers -DifferenceObject $mycurrentusers -property samaccountname
    $mydiff
    foreach($i in $mydiff)
    {
        if($i.SideIndicator -eq "=>"){Add-AdGroupMember -identity $mygroup -members $i.samaccountname}
        else {Remove-AdGroupMember -identity $mygroup -members $i.samaccountname -confirm:$False}
    }
}

The above provides a differential solution by splitting the single very large group into a series of 26 smaller, more manageable groups. Then we can wrap the 26 groups with a query-based distribution group for simplified delivery to clients using

new-DynamicDistributionGroup All_Employees -OrganizationalUnit "OU=My OU,DC=liquidobject,DC=com" -RecipientFilter {RecipientContainer -eq "OU=EmployeeGroups,My OU,DC=liquidobject,DC=com"}
, , ,
March 21, 2013 at 7:58 pm Comments (0)

FreeNAS and renaming ZFS datasets

While not a feature of FreeNAS at least as of version 8.3 you can actually rename your ZFS datasets. The rename command is feature of ZFS and can be accomplished through the shell.

First, use: zfs list

[root@NAS-1] /mnt/RaidZ# zfs list
NAME                  USED  AVAIL  REFER  MOUNTPOINT
RaidZ                 306G  2.36T  53.3K  /mnt/RaidZ
RaidZ/Backups        8.19G  91.8G  8.19G  /mnt/RaidZ/Backups
RaidZ/Test_gzip6  17.4G  32.6G  17.4G  /mnt/RaidZ/Test_gzip6
RaidZ/Photos            5G  20.0G  40.0K  /mnt/RaidZ/Photos
RaidZ/Transfer       3.70G  46.3G  3.70G  /mnt/RaidZ/Transfer

 

The first column generated will give you the actual name of your dataset. In my case I wanted to rename “Test_gzip6” to “Test1”

zfs rename RaidZ/Test_gzip6 RaidZ/Test1

Which results in:

[root@NAS-1] /mnt/RaidZ# zfs list
NAME                  USED  AVAIL  REFER  MOUNTPOINT
RaidZ                 306G  2.36T  53.3K  /mnt/RaidZ
RaidZ/Backups        8.19G  91.8G  8.19G  /mnt/RaidZ/Backups
RaidZ/Test1  17.4G  32.6G  17.4G  /mnt/RaidZ/Test1
RaidZ/Photos            5G  20.0G  40.0K  /mnt/RaidZ/Photos
RaidZ/Transfer       3.70G  46.3G  3.70G  /mnt/RaidZ/Transfer

Pretty straight forward, the syntaxing is the only hangup because it’s not looking for the true path in this case which was /mnt/RaidZ/Test_gzip6 but just the full dataset name.

, , ,
March 17, 2013 at 8:03 pm Comments (0)

FreeNAS 8.3 and VMware ESXi’s VMXNet3 adapter

The built-in networking support under FreeNAS 8.3 is only the e1000 adapter and while it does “work” it really lacks performance in a virtual environment. To get around this limitation we need to install VMware Tools to support more modern networking adapters. While this question is ask time and time again in the FreeNAS forums and around I never see a straight forward solution for adding the VMXNet3 adapter. So here we go.

We’ll assume you already have your VM deployed with one e1000 and one vmxnet3 adapter and we are just loading in the drivers.

 

Add Perl

Pull up the shell or connect via SSH to your FreeNAS VM

mount -urw /
cd /tmp
pkg_add -r perl -K
tar -xjf perl.tbz
cp lib/perl5/5.12.14/mach/CORE/libperl.so  /lib

(the build number will change as time goes on)

Add compat6x

pkg_add -r compat6x-amd64

Install VMware Tools

It is assumed you are installing with the default options.

Install VMware tools as normal via the "Install/Upgrade VMware tools" menu option
mkdir /mnt/cdrom
mount -t cd9660 "/dev/iso9660/VMware Tools" /mnt/cdrom
cd /tmp
tar zxpf /mnt/cdrom/vmware-freebsd-tools.tar.gz
umount /mnt/cdrom
cd vmware-tools-distrib
./vmware-install.pl
/usr/local/bin/vmware-config-tools.pl

Ignore the failed notice for the memory manager. At this point VMware Tools is installed but still needs some tweaking.

VMware tools tweaking

vi /usr/local/etc/rc.d/vmware-tools.sh
Look for: if [ "$vmdb_answer_VMHGFS_CONFED" = 'yes' ]; then    and change yes to xyes
Look for: if [ "$vmdb_answer_VMMEMCTL_CONFED" = 'yes' ]; then    and change yes to xyes
Look for: if [ "$?" -eq 0 -a "$vmdb_answer_VMXNET_CONFED" = 'yes' ]; then    and change yes to xyes
save and close vi (escape wq enter)
rm /etc/vmware-tools/not_configured
reboot

Now within the FreeNAS WUI (Web User Interface) add an additional network adapter, you’ll see vmxnet3 adapter called “vmx3f0”.

 

I’m seeing the following differences when sequential data (4GB iso) to and from a test system via SSD and Gigabit infrastructure.

e1000 Adapter

  • Read: 50 MB/sec to 59MB/sec (for first 2GB then 73 MB/sec)
  • Write: 33.0 MB/sec to 35 MB/sec

VMXNet3 Adapter

  • Read: 93MB/sec to 95MB/sec
  • Write: 29.5 MB/sec to 42.1 MB/sec

My VM configuration

  • vCPU: 3
  • Ram: 6GB
  • Drives: 4GB vmdk, 3×1.5TB virtual RDM
  • Raidz
  • NIC: e1000(management),VMXNET3(data)
  • VM Hardware Version: VMX-09

My host config

  • CPU: Dual Xeon e5320’s
  • Ram: 24GB ECC DDR2
  • Controllers: IBM M1015 (IT firmware), LSI 8308ELP
  • Drives: 2x500GB(hardware mirror), 3×1.5TB(7200.11)(FreeNAS virtual RDM’s)
  • NIC: Onboard Intel 1000pro
  • OS: ESXi 5.1 Update 1

Sorry, no VT-d on this host to pass through the M1015 which may be giving me a small amount of overhead running the virtual RDM’s.

, , , , , , ,
March 13, 2013 at 8:24 pm Comment (1)

SCOM 2012 database grooming

Approximately three months back we migrated to SCOM 2012 and have been slowly rebuilding our configuration. In defining the configuration we forgot one key part, database grooming customization. By default some data is kept for a couple of days but a lot of day is kept for either 180 days or 400 days. While in a lab environment this may be ok since you are only monitoring a few systems in production this will cause some unexpected database growth issues. Below you can see the defaults configured.

 
Dataset name                   Aggregation name     Max Age     Current Size, Kb
—————————— ——————– ——- ——————–
Alert data set                 Raw data                 400         8,440 (  0%)
Client Monitoring data set     Raw data                  30             0 (  0%)
Client Monitoring data set     Daily aggregations       400            16 (  0%)
Configuration dataset          Raw data                 400       133,616 (  0%)
DPM event dataset              Raw data                 400             0 (  0%)
Event data set                 Raw data                 100       594,592 (  2%)
Microsoft.Exchange.2010.Dataset.AlertImpact Raw data                   7             0 (  0%)
Microsoft.Exchange.2010.Dataset.AlertImpact Hourly aggregations        3             0 (  0%)
Microsoft.Exchange.2010.Dataset.AlertImpact Daily aggregations       182             0 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.Availability Raw data                 400            16 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.Availability Daily aggregations       400             0 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.TenantMapping Raw data                   7             0 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.TenantMapping Daily aggregations       400             0 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ActiveUserMailflowStatistics.Data Raw data                   3        17,424 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ActiveUserMailflowStatistics.Data Hourly aggregations        7       225,104 (  1%)
Microsoft.Exchange.2010.Reports.Transport.ActiveUserMailflowStatistics.Data Daily aggregations       182       104,592 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ServerMailflowStatistics.Data Raw data                   7         1,616 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ServerMailflowStatistics.Data Hourly aggregations       31         6,480 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ServerMailflowStatistics.Data Daily aggregations       182           688 (  0%)
Performance data set           Raw data                  10     4,984,944 ( 13%)
Performance data set           Hourly aggregations      400    26,558,360 ( 69%)
Performance data set           Daily aggregations       400     3,047,320 (  8%)
State data set                 Raw data                 180        37,280 (  0%)
State data set                 Hourly aggregations      400     2,481,936 (  6%)
State data set                 Daily aggregations       400       117,280 (  0%)
 

To prevent the database from growing to hundreds of GB we need to adjust the retention policies. In order to accomplish this we need to download the dwdataarp.exe utility from Microsoft at: http://blogs.technet.com/b/momteam/archive/2008/05/14/data-warehouse-data-retention-policy-dwdatarp-exe.aspx

With this installed open up an administrative command line on the SCOM server we can begin.

First run: dwdatarp.exe -s localhost -d “OperationsManagerDW”
This will show you your current configuration, now we need to tweak some of the retentions. The below example is a mix of retention periods in an environment with Exchange 2010 and DPM 2012 installed.

dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Alert data set" -a "Raw data" -m "30"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Event data set" -a "Raw data" -m "30"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Client Monitoring data set" -a "Daily aggregations" -m "60"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Configuration dataset" -a "Raw data" -m "30"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "DPM event dataset" -a "Raw data" -m "30"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Microsoft.Exchange.2010.Reports.Dataset.Availability" -a "Raw data" -m "30"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Microsoft.Exchange.2010.Reports.Dataset.Availability" -a "Daily aggregations" -m "90"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Microsoft.Exchange.2010.Reports.Dataset.TenantMapping" -a "Daily aggregations" -m "90"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Microsoft.Exchange.2010.Reports.Transport.ActiveUserMailflowStatistics.Data" -a "Daily aggregations" -m "90"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Microsoft.Exchange.2010.Reports.Transport.ServerMailflowStatistics.Data" -a "Daily aggregations" -m "90"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Performancedata set" -a "Raw data" -m "7"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Performance data set" -a "Hourly aggregations" -m "14"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "Performance data set" -a "Daily aggregations" -m "90"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "State data set" -a "Raw data" -m "7"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "State data set" -a "Hourly aggregations" -m "14"
dwdatarp.exe -s localhost -d "OperationsManagerDW" -ds "State data set" -a "Daily aggregations" -m "90"

 

 

After making the change and waiting for the automated grooming to complete I ended up dropping the database size from 42GB and growing to 21GB.

 

Dataset name                   Aggregation name     Max Age     Current Size, Kb
—————————— ——————– ——- ——————–
Alert data set                 Raw data                  30         4,656 (  0%)
Client Monitoring data set     Raw data                  30             0 (  0%)
Client Monitoring data set     Daily aggregations        60            16 (  0%)
Configuration dataset          Raw data                  30       133,552 (  1%)
DPM event dataset              Raw data                  30             0 (  0%)
Event data set                 Raw data                  30       352,040 (  2%)
Microsoft.Exchange.2010.Dataset.AlertImpact Raw data                   7             0 (  0%)
Microsoft.Exchange.2010.Dataset.AlertImpact Hourly aggregations        3             0 (  0%)
Microsoft.Exchange.2010.Dataset.AlertImpact Daily aggregations       182             0 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.Availability Raw data                  30            16 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.Availability Daily aggregations        90             0 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.TenantMapping Raw data                   7             0 (  0%)
Microsoft.Exchange.2010.Reports.Dataset.TenantMapping Daily aggregations        90             0 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ActiveUserMailflowStatistics.Data Raw data                   3        17,680 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ActiveUserMailflowStatistics.Data Hourly aggregations        7       226,384 (  1%)
Microsoft.Exchange.2010.Reports.Transport.ActiveUserMailflowStatistics.Data Daily aggregations        90       104,144 (  1%)
Microsoft.Exchange.2010.Reports.Transport.ServerMailflowStatistics.Data Raw data                   7         1,616 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ServerMailflowStatistics.Data Hourly aggregations       31         6,416 (  0%)
Microsoft.Exchange.2010.Reports.Transport.ServerMailflowStatistics.Data Daily aggregations        90           688 (  0%)
Performance data set           Raw data                  10     5,047,512 ( 30%)
Performance data set           Hourly aggregations       14     6,600,016 ( 39%)
Performance data set           Daily aggregations        90     3,047,104 ( 18%)
State data set                 Raw data                   7        23,840 (  0%)
State data set                 Hourly aggregations       14     1,064,864 (  6%)
State data set                 Daily aggregations        90       117,088 (  1%)

 

Also, if you want to speedup the time it takes for the cleanup to occur from within SQL you can run the following command to reduce the time period between cleanup.

update StandardDatasetAggregation set GroomingIntervalMinutes = '11' where GroomingIntervalMinutes = '240'

After cleanup has finished, run the below to change the configuration back to what it was

update StandardDatasetAggregation set GroomingIntervalMinutes = '240' where GroomingIntervalMinutes = '11'
March 11, 2013 at 11:44 am Comments (0)

Counter Intelligence via Palo Alto Networks

As an aside from most posts found here, I found a fair amount of unusual traffic recently.  Last week I ended up looking up some models of Palo Alto firewalls and even downloaded a smartphone application of theirs. Nothing really out of the ordinary until  this past Wednesday when I see a large influx of traffic to the site.

Site Hits

In the above graphic you can large influx of probing hits coming from Palo Alto Networks. I can only assuming per other farming tactics I’ve seen in the past the data flows as follows.

  1. You visit Vendor XYZ’s site
  2. Vendor XYZ parses their website logs looking for those users who are making multiple queries against the products portion of the company site
  3. Vendor XYZ performs a bot query hitting up the site client’s IP to see if there is a website and if contact information can be captured
  4. A followup script takes the results and if enough information is capture then is forwarded to the pre-sales department
  5. My phone rings

Really? Do you think I’ll buy a PA-5050 or PA-5060 because you cold-call me mysteriously after I visit your website?

 

, , ,
March 10, 2013 at 8:31 am Comments (0)

NAS4Free under ESXi

 

One surprising thing I noticed when testing out NAS4Free is the lack of documentation with regards to installation on VMware. I can understand a viewpoint that a NAS is a NAS and not to be anything else, but what about working loads where that kind of raw performance is not required (granted the virtualization overhead these days should be within 5-10% of physical). In any case the below instructions are written with running ESXi 5.1 with NAS4Free 9.1.0.1, for ease of reading the directions are broken down into three sections.

 

 

Initial download and VM configuration

 

1)      Download the latest x64 release at http://www.nas4free.org/downloads.html

2)      Create a new custom Virtual Machine (Assume defaults unless otherwise specified)

a)      Guest Operating System – Other – FreeBSD 64-Bit

b)      Virtual sockets – 3  (you can use less but I was seeing a significant performance hit with less than 3)

c)      Memory: 4GB (not a hard requirement but in general the more the better)

d)     Network

i)        Number of NICs: 2

ii)      NIC 1 Adapter: e1000
(The e1000 will be used for management only as the default NAS4Free install does not correctly load the VMXNet3 driver)

iii)    NIC 2 Adapter: VMXNet3
(The VMXNet3 adapter will be used for Samba/NFS/iSCSI traffic)

e)      SCSI Controller: LSI Logic Parallel

f)       Disk: 4GB, can be thin provisioned

3)      Finish creating the VM

4)      Edit the VM

5)      Add  your additional hard disks and assign them starting at 1:0, 1:1, 1:2 (virtual RDM’s are an option as well). One VMDK per disk unless your really just feature evaluating the setup.

a)      Optionally if supported you could use Direct-Path to pass through your favorite SCSI controller

6)      Change your newly created SCSI Controller to: LSI Logic SAS
(Paravirtual does not function with the version of Vmware tools pre-bundled with the NAS distro)

7)      Select “OK” to complete the modifications

 

 

NAS4Free base install

 

1)      Boot the VM and start it off of the recently downloaded ISO

2)      Walk-through the normal installer screens selecting” Install ‘embedded’ OS on HDD/FLASH/USB”
(Full is extremely buggy at this point and only really used for NAS4Free developers)

3)  Install onto the 4GB volume

4)  After the install completes, reboot and disconnect the ISO volume

5)  Configure your mangement IP

 

 

Configuring your new VM

 

1)      Login to the web administration to the new VM

2)      Select System –> Advanced

3)      Select rc.conf

4)      We need to add some custom tuning for the VM

a)      Add – Name: vmguestd_enable – Value: Yes

b)      Add – Name: vmsetup_enable – Value: Yes

c)      Optionally (useful for debugging sometimes)

i)        Add – Name: dmesg_enable – Value: Yes

5)      Apply changes

6)      System –> Reboot

 

At this point the VM should be fully useable. If running into performance problems TOP within the VM and the vSphere performance graphs should be where to start looking. VM CPU usage and disk latency are generally the first points of issue.

Enjoy.

 

, , ,
March 9, 2013 at 4:45 pm Comments (12)