Citrix XenDesktop is an Extension of The Server Virtualization

Citrix XenDesktop is an extension of the server virtualization (XenServer) and application virtualization (XenApp) products, utilizing virtualized, dynamically provisioned desktop O/S’s  streamed to the client device, whether that’s a Citrix-Ready “Desktop Appliance”, or a repurposed Windows XP box running the “Desktop Receiver”.

XenDesktop is available in several versions:

Express: Is free, for POC builds of up to ten users
Standard Edition: Includes desktop brokering with “Desktop Delivery Controller”, and secure remote access using “Citrix Access Gateway”.
Enterprise Edition: Adds on desktop provisioning with “Provisioning Server for Desktops”, which saves on storage costs by dynamically provisioning desktops based on a profile.
Platinum Edition: Adds performance monitoring, WAN optimization, and EasyCall.

Unitek’s “CTX-2201 AI” covers XenDesktop Enterprise Edition, preparing the student for the “1Y0-A03” exam, which leads to the “Citrix Certified Administrator for XenDesktop 2” industry standard certification in the latest technology.

Unitek’s “CXS-2001i” covers XenServer 5, the server virtualization hypervisor from Citrix.

Unitek’s “CTX-1259BI+AD/RM Combo” covers XenApp5, the industry standard application virtualization platform.

Visit our Citrix Courses.

Data ONTAP and Space Management – Part 7

With the combination of Data ONTAP 7.2 and flexible volumes we have some new options for managing space in volumes that contain LUNs.  Obviously, we still have to provide a free block when the host wants to write, but now we have a new block pool in the aggregate we can pull from.  We also have the option of automatically deleting snapshots as a source of free blocks.

If we set the fractional reserve to 0% and then set the autosize option on a volume, the volume can grow when it needs more space by pulling it from the aggregate.  Effectively the aggregate is supplying the pool of available blocks.

Effectively the aggregate is providing a pool that can be shared across all the volumes it contains.  It is also very unlikely that all the LUNs in all the volumes will suddenly become extremely active at the same time.  Therefore it may make sense to set aside a free space pool that is less than what we would have provided to support a 100% space reserve for every LUN in the aggregate.

This is especially true when we consider that the autosize option is typically combined with automatic deletion of snapshots.

The following command configures vol2’s autosize options:

In this case I have configured vol2 to grow to a max size of 1 Gigabyte in 100 megabyte steps.  I can limit the maximum size the volume can achieve and I can configure the size of the increments it uses to grow.

Automatically growing volumes is generally combined with automatic deletion of snapshots.  You can control which policy you want to implement first with the following option:

In this example vol2 will first try growing the volume before deleting snapshots.  Once the volume has reached maximum size it will start deleting snapshots to free blocks.  Remember, we are not changing the size of the LUN, we are adding fresh blocks to the volume which can be used to as provide the LUN substitute blocks for block updates or overwrites.

Which is better depends on your storage environment.  You can control this behavior individually for each volume.  If you tend to keep a lot of snapshots, perhaps some longer than necessary just to be safe, then it might be better to delete snapshots first.  If you have some extra space in your aggregate, perhaps for performance reasons, then it might be better to auto-grow.

Next we’ll take a look at how to control which snapshots are deleted.

IPv6 – Part 3

Global Unicast, Link-local, Site-local, Unique-local, Multicast
In addition to the Global Unicast addresses that start with either a 2 or 3 and the reserved “::1” for localhost, you will need to recognize and respond to: FF, FE80, FEC, FC, and FD.

Multicast – FF
First, there is no Broadcast in IPv6 and that will take a while to adjust to – the lack of broadcast. In IPv4, when a host system did a “DHCP Discover”, the broadcast had to be processed by all the systems, not just the DHCP servers. To reduce the performance bleed of systems, IPv6 uses the more targeted Multicast. Any IPv6 address which starts with FF is a multicast address. Example – FF02::1:2 is reserved for DHCP agents (server or relay agent) – RFC 2375.

NOTE: With IPv6, there may not be a need for DHCP, as hosts have the option to auto configure themselves using the new ICMPv6 router solicitation/advertisement (router discovery).

Link-local addresses – FE80::/10 (FE8, FE9, FEA, FEB)
As mentioned earlier, the most common support call is: What’s an FE80? Well, with a small number of systems, it’s always been convenient to be able to just plug everything together, power-up, and have all the systems find each other and start communicating.

With IPv4, the first part of the configuration (host id) can be provided by APIPA – Automatic IP Addressing.  When a system doesn’t receive a response to its request for automatic address assignment (DHCP Discover), it’s allowed to generate an address – in the form of: 169.254.random. Advantage – all systems on the same segment (link) can generate a unique ‘random’ address and start communicating. Limitation:  packets are not routed – communication is limited to the local segment (link).

With IPv6, this is referred to as a Link-local address and takes the form of – FE80:/10. So, in a small, simple environment (single link/segment), there’s instant communication. However, in a normal corporate environment (multiple, routed, networks), like APIPA, you weren’t assigned a “useable”, routable address. And you can answer the question, “What’s an FE80, and why can’t I get to the server?”

Site-local – FEC0::/10 (FEC, FED, FEE, FEF)
When it became obvious that IPv4 would soon run out of addresses, NAT (network address translation) was there to save the day. Some of the still available addresses (not the most attractive) were set aside and labeled as “Private”, with normal (routed on the Internet) addresses labeled as “Public”. The Private addresses would not be routed by Internet routers (never appear on the Internet), so they could be used over and over by any company. NAT would provide the Public (external) to Private (internal) translation.

In IPv4, the Reserved Private addresses are: 10/8, 172.16-31/12, and 192.168/16 – routed within a company, but intentionally not routed between companies.

In IPv6, these are referred to as Site-local and use addresses in the range of FEC to FEF or FEC0::/10. Example: FEC0:0:0:FFFF::1 is the default assumed address for a system’s internal DNS server.

I would like to say that we’ve finished your crash course on IPv6 addressing and special addresses, but there’s one more – the newer Unique-local, that officially deprecates Site-locals.

Unique-local – FC00::/7 (FC and FD)
RFC 3879 …”As currently defined, site local addresses are ambiguous: an address such as FEC0::1 can be present in multiple sites, and the address itself does not contain any indication of the site to which it belongs.”…

Unique-local addresses serve the same purpose as Site-Local, but made provisions for a “Unique” Private address.

The upper 64 bits (network address) are broken down into 3 fields: the first 8 bits would identify the address as a Unique-local, then the next 40 bits would be a ‘global id’, with the final 16 bits being a ‘subnet id’. The ‘global id’ could identify a specific company, then the ‘subnet id’ could be used to identify “sites” (locations) within a company.

The top 7 bits identify the address as a Unique-local. Bit 8 is the difference between FC the ‘managed’ addresses and FD ‘unmanaged’ addresses. With FC, the 40-bit global id could be assigned (managed) by a future organization (e.g. ULA-Central). With FD, companies simply use a pseudo-random algorithm to generate the 40-bit global id. With either system, a company would then use the 16-bit subnet id to identify their internal sites (e.g. geographic locations). Every internal network within a large world-wide corporation can be uniquely identified for reliable routing.

Pop quiz:
Given a multiple choice question of:
A:     FF01
B:    2001
C:    FE80
D:    FD92
E:    FEC0

Which is a Multicast address?

Which is a Global Unicast address?

Which is a Link-local address?

Which is a Unique-local address?

Which is the deprecated Site-local?

Stop and Think: CCSP

Cisco Certified Security Professional (CCSP), when you stop to think about the role and responsibilities a security professional takes sometimes it is scary.  You are charged with the confidentiality of your organizations information, what could possibly go wrong?  Well one thing that I have unfortunately seen is when something does go wrong they data owners are normally looking for someone to take the blame / fall.  Being the security professional for your organization also means you get to take the blame.  The blame is different then what you may be used to… As a CCNP your job is to keep things working, move data, and allow communications.  When something goes wrong you get yelled at while you are trying to fix it, once it is fixed life goes on. Someone will normally not be fired due to a piece of hardware failing (assuming you have contingency plans to replace/repair and resolve the issue).  As a security professional (CCSP), when something goes wrong what happens.  Someone gains access to information which they shouldn’t be; what are the repercussions?  Someone will most likely have to take the blame and it’s not good enough to say oops my bad. Most defiantly someone will get fired. But could there be lawsuits for the failure? Maybe that is one if the differences between the salaries of a CCNP vs. a CCSP, the stress and the vulnerability of your position.  No one ever said you would get paid well doing an easy job.

Failure When Upgrading to The CRM 4.0 Outlook Client

If you’ve upgraded to Microsoft CRM 4.0 and your users lose their Microsoft CRM functionality in the Outlook client, try these steps to correct the problem:

  1. In Outlook, go to Tools -> Customize.
  2. Click the Toolbars tab.
  3. Remove the CRM tool bar listing.
  4. Click on each other toolbar listing and click Reset on each one.
  5. Click the Options tab and click the “Reset menu and toolbar usage data”.
  6. Close this box.
  7. Click Tools->Trust Center.
  8. Click Add-Ins in the left navigation bar.
  9. At the bottom of this screen, choose “COM Add-ins” then the “Go” button.
  10. Click on the CRM Dynamics item then click the “Remove”.
  11. Close Outlook.
  12. Open Outlook and verify that the CRM menu bar and task bar items are removed.
  13. Go to Tools->Trust Center.
  14. Click Add-Ins in the left navigation bar.
  15. At the bottom of this screen, choose “COM Add-ins” then the “Go” button.
  16. Click Add and add the CRM add-in back by navigating to the install location (by default this is C:Program FilesMicrosoft Dynamics CRMclientbincrm) and choose the file “crmaddin.dll”.

This has been the fix for all of our Microsoft CRM 3.0 clients that upgraded to Microsoft CRM 4.0!

DG
Microsoft CRM Consultant
Unitek Microsoft CRM Services

Update: Citrix XenApp 5

Citrix announced last week the the XenServer 5 product will be free, in a move to shake up the competition between VMware’s ESX 3.5 Product – (now in “Update 3” with more features), and the hypervisor from Citrix. Unitek is now offering the official 2-day Citrix XenServer 5 training course (CXS-200-1i), in addition to the VMware VI3 5-day bootcamp we have been offerring for over a year now, (recently updated with the latest additions, including “DPM – Distributed Power Management” and “Storage VMotion”), and we’re putting the peices together to keep you on top of the latest changes in a shifting industry.

Space Management and Data ONTAP– Part 6

We have been looking at snapshot space management primarily from a NAS perspective.  From this perspective the primary technique used to deal with storage tied to the snapshots is the mechanism of the snapshot reserve.  And we have seen that all the snapshot reserve really does is set aside some space when the volume is created so that it will be available for overwrites of blocks that are tied to snapshots.  Essentially this is used to hide space usage from snapshots, but it does not affect our ability to execute a snapshot.

The situation with SAN and LUNs drives off of these ideas, but is slightly more complex.  We will be looking at this from the perspective of traditional volumes and some new capabilities available with flexible volumes.

Essentially, the problem is the same.  Once blocks in the WAFL file system are part of a snapshot they are protected.  They become read-only blocks, so to do updates we have to be able to supply unused blocks.  There is more than one way to do this.

In the world of traditional volumes we have limited options.  Traditional volumes are also aggregates.  They own their own disks and the problem has to be resolved within this context.  This is done through space reservations and the fractional reserve.

Here is an example of the lun setup script.  One of the prompts asks do we want the LUN to be space reserved and gives the explanation that this will guarantee that writes to the LUN will never fail.

Why do we need such a guarantee?  If we are not using snapshots then we really don’t need this guarantee.  But if we are taking snapshots then some blocks within the LUN will become read-only when the snapshot is taken.  Since the host operating system is not aware of the snapshot, Data ONTAP must have a pool of blocks to supply the host for overwriting blocks held in snapshots.  This pool is set aside when the LUN is created when we say “yes” to the space reserved prompt.

By default the size of this pool is equivalent to the size of the LUN.  This means the volume must be large enough to contain both the LUN, the space reserved for overwrites and the blocks tied up by snapshots.  To support a 100 MB LUN we would need volume that was at least 200MB plus some amount to support the blocks tied up in snapshots.

We can adjust the space reservations with a parameter called the fractional reserve.  The fractional reserve is applied to space reservations.  It is set to 100% by default so the block pool is able to support the LUN even if the host were to update every block in the LUN while simultaneously every block in the LUN were locked up in one or many snapshots.  This is why we can say that data writes will never fail.  If the number of blocks locked by a snapshot were to set up the situation where the number of free blocks left in the volume were less than the amount of space reserved then the snapshot would fail.  The number of free blocks in the volume would never be less than the number of blocks allocated to the LUN.

We can reduce the amount of space reserved by adjusting fractional reserve.  The following command would set the fractional reserve to 70% instead of 100% for vol2:

This decreases the amount of space reserved, but it is possible to create a situation where there may not be free blocks available in the volume when the host tries to update a block in the LUN.  If this happens the write will fail.

With traditional volumes, space reservations combined with a fractional reserve of 100% was the only way we could be sure LUN writes would never fail.  With flexible volumes and Data ONTAP 7.2, we have some new options.