Archive
GREAT VIDEO – #Citrix #XenDesktop vs. #VMware #Horizon #View installation video
This is really funny! Have a look at this video to see how you can compare a XenDesktop and a Horizon View installation side-by-side!
And another thing that is kind of funny is that VMware still compares Horizon View with XenDesktop 5.6: https://www.vmware.com/files/pdf/techpaper/VMware-View-vs-Citrix-XenDesktop-Datasheet.pdf
//Richard
Making #OpenStack Grizzly Deployments Less Hairy – #Puppet, #PuppetLabs
Today, I’m excited to announce a new module from Puppet Labs for OpenStack Grizzly. I’ve been working on this module with the goal of demonstrating how to simplify OpenStack deployments by identifying their independent components and customizing them for your environment.
The puppetlabs-grizzly module is a multi-node deployment of OpenStack built on the puppetlabs-openstack modules. There are two core differences in how it handles deploying OpenStack resources. First, it uses a “roles and profiles” model. Roles allow you to identify a node’s function, and profiles are the components that describe that role. For example, a typical controller node is composed of messaging, database and API profiles. Roles and profiles allow you to clearly define what a node does with a role, while being flexible enough to mix profiles to compose new roles.
The second difference is that the module leverages Hiera, a database that allows you to store configuration settings in a hierarchy of text files. Hiera can use Facter facts about a given node to set values for module parameters, rather than storing those values in the module itself. If you have to change a network setting or password, Hiera allows you to change it in your Hiera text file hierarchy, rather than changing it in the module.
Check out parts 1 and 2 of the demo, which walks you through how to deploy OpenStack with the puppetlabs-grizzly module.
Multi-node OpenStack Grizzly with Puppet Enterprise: Deployment (Part 1 of 2)
How To: #XenMobile #MDM 8.5 Deployment Part 3: Policies – #Citrix
And here U have part 3 of Adams great blog post series!
In this 3rd part of my 7 part series on XenMobile MDM 8.5 we will focus on policies. Policies within MDM allow you to control a multitude of features on your end users mobile devices, including: WiFi, Email, VPN, Location Services, most all functionality of the device (camera, FaceTime, etc), AppStore access, etc. Most configuration variations you do to control and limit/restrict/configure your end users devices will be done from this tab. This tab is also the location where we can create some automated actions that include notifying your users when they have fallen out of compliance.
If you would like to read the other parts in this article series please go to:
- How To: XenMobile MDM 8.5 Deployment Part 1: Installation
- How To: XenMobile MDM 8.5 Deployment Part 2: Basic Configuration
In this article I was to cover a “base” set of policy configurations that will give you a feel of how the policies work in general. By no means does this cover the breadth of what you can do with MDM, but it at least gives you a glimpse.
I want to accomplish the following in this article:
- Set a passcode policy on the device
- Block iCloud from syncing documents
- Preconfigure a WiFi network on my device (so that your users could come into the office with WiFi already configured and never have been given the password)
- Blacklist Dropbox, Box, and SkyDrive applications
- Notify the user their device as Out of Compliance (OoC) if those apps are installed
- Mark the device as OoC in the dashboard
.Configure a Passcode Policy
How to: #Citrix #XenMobile 8.5 MAM upgrade! Part 2 – #StoreFront, #AppController, #NetScaler
Hi again!
If you haven’t read Part 1 then I highly recommend doing so prior to going directly to the upgrade that we’re covering in this post!
Prepare for a journey in this post about Citrix StoreFront upgrade, uninstallation, console and how messy it could be! NOT all the time, sometimes it “just works”! 😉
My little NetScaler is already upgraded to 10.1 so unfortunately I couldn’t take you on that journey as well, so we’ll start with the StoreFront upgrade from 1.2 to 2.0 in this post. These are the steps that we need to cover as highlighted in the migration guide that seems very short and straight forward:
Upgrade StoreFront 1.2 to 2.0.
- Logon to the StoreFront server console.
- Upgrade StoreFront by running the StoreFront 2.0 installer as an administrator.
- When the upgrade is completed, open StoreFront administration snap-in, remove CloudGateway controller from each store as this will be moved in the migration solution.
- Open NetScaler Gateway Properties and for each gateway defined and change the version field in settings from 9.x to 10.0.x or later.
- Test the configuration by logging on through web browser or Citrix Receiver.
- Verify if the users are able to login and authenticate to StoreFront defined stores configured.
Is it this easy?
Ok, I’ve downloaded the 2.0 installer, and I’m logged on to the server.
Before we even start the upgrade there are things that could go wrong in removal or upgrades of StoreFront. And one that I’ve seen cause a lot of headache for a lot of people out there is that they have the Windows Firewall service disabled. Though the installation and removal wants to delete or add these rules the installation will fail unless this service is running. As you can see in this picture below you see the FW rule added in StoreFront 1.2:
So let’s verify that the Windows FW service is started, and it is!
I’ll now start the installation by double-clicking the StoreFront 2.0 installer!
What is this popup that came directly after starting the installer?
Wait, ok so you guys at Citrix couldn’t ask me whether you could do this for me? My plan is to upgrade, so please just add a little step in your upgrade program that does this for me… change request #1 for the next SF release and it’s upgrade process! Verify pre-requisites or deal with them!
The IT Melting Pot! 