Tiny Deathstars of Foulness

When you are configuring ExtremeZ-IP as a print server, you will need to set up and configure each printer. However, if you already have setup and configured printer queues for the Windows server, you can import existing queues into ExtremeZ-IP. This can be done programatically via the ExtremeZ-IP EZIPUTIL command line tool. EZIPUTIL has a number of options, whereby the SERVER option is used to configure global settings for ExtremeZ-IP, VOLUME is used to create, edit and delete print queues and PRINT is used to manage shared print queues. Each of the options also has a number of switches for the feature(s) that are being managed. These are structured as standard switches that are used in Windows batch scripting. The /IMPORT switch can be used to import print queues. By defining the WINDOWS setting for the import, you will recreate all printer queues from Windows. This command would look like the following: EZIPUTIL PRINT /IMPORT:WINDOWS Once the command has been completed, you can then list printer queues using the /LIST switch: EZIPUTIL PRINT /LIST Once you have created printer queues you will often end up needing to remove a queue or three. To remove a printer queue, you will use the /REMOVE switch along with a /NAME switch to specify the printer queue that you are removing. For example, to remove a queue called Accounting_499 you would use the following command: EZIPUTIL PRINT /REMOVE /NAME:Accounting_499 The VOLUME option has a similar feature in the /REPLICATE_SMB switch, which allows you to replicate existing SMB/CIFS shares: EZIPUTIL VOLUME /REPLICATE_SMB The /REMOVE switch can also be used with the VOLUME option. If you have created volumes you can also remove those from the command line. For example, to remove a shared volume called Accounting_Files, you would use the following command: EZIPUTIL VOLUME /REMOVE /NAME:Accounting_Files

March 1st, 2011

Posted In: Mac OS X Server, Mass Deployment, Network Infrastructure, Windows Server

Tags: , , , , , , , ,

You have two switches and you’re thinking that you’ll use the GBIC from your old switch on you new switch.  You have an Xsan and you have a bunch of GBICs laying around and you want to know if they’ll work.  You have a fiber run and you want to use a transceiver.  Etc. This is a tricky question.  The GBICs should all work.  The general rule of thumb though is, if you use the same GBIC on both ends then you shouldn’t have a problem.  But, it’s also important that (for whatever reason) some manufacturers do require certain GBICs either to actually interface or just to support an interface.

July 8th, 2007

Posted In: Network Infrastructure, Xsan

Tags: , , , , ,

No one ever got fired for buying Cisco.  But, I recently saw a shop where they went from Cisco to Enterasys (thanks for showing off your backbone Todd).  I must say that I really liked the Enterasys switches. I looked them up and they are about 1/2 the cost of Cisco.  They have great tech support and are very easy to configure, even though it’s a command line interface.  The only complaint I have about them is the web interface is good for reviewing your setup but inadequate  for configuration – but is good for looking at the switch configs. Maybe in time this will mature…  I don’t know if they can go to the 10,000+ environments though…  Oh, and it required zero config to do link aggregation, which was weird – but cool… Now, I have really been liking what Foundry is doing with their switches. And Juniper.  If you play your cards right you can even get free training with Juniper, which is pretty cool – and sometimes they give hard core sweetheart deals to larger shops that are switching over to their platform from Cisco. Of course there are hundreds of other switch manufacturers.  The only other ones I’ve seen in really large install bases are HP (which I hear mixed reviews on from Mac guys) and Extreme Networks (again mixed reviews for Mac) and some Allied Telesys Switch Blades (great review but only seen them once – 4000 series blades – with fiber to ring and ethernet to classrooms in the same chassis – it stuck out to me ’cause we used to sell a lot of allied switches and I didn’t know they made blades yet).

June 27th, 2007

Posted In: Network Infrastructure

Tags: , , , , ,

Extreme core switch

June 21st, 2007

Posted In: Network Infrastructure

Tags: ,

The functional layers for swiching environments in the Data Center are often architected around three layers, commonly referred to as The Cisco Three-Layered Hierarchical Model:

  • The Core Layer connects the Aggregation Layers. Typically, the Core Layer utilizes high performance low latency Layer 3 switches (often 10 gig Ethernet and/or 10 gig fiber).
  • The Aggregation Layer provides services, such as Load Balancing and SSL Optimization.  Access Layer switches typically use the Aggregation Layer for connecting to the Core Layer.
  • The Access Layer includes the hubs and switches that connect client systems.

October 4th, 2006

Posted In: Network Infrastructure

Tags: , , , ,