Thursday, 30 July 2009
Monday, 6 July 2009
Migration
Just a quickie to say despite what I've said in the past I am going to migrate this blog to wordpress as since I've started using it as a backup for blogger I've actually discovered I prefer wordpress.
So dont be surpised if you check in over the next day or two and find you get the odd DNS funkyness as it re-aligns with wordpress.
Cheers Ears
Tuesday, 30 June 2009
Not Much Going On!
Well due to a thunder storm and various power cuts over the past few days I have not managed to get any studying done. However at work I had a little triumph in getting our wyse thin clients working correctly at our remote site.
So since the site has been up the wyse clients have required configuring to get them to connect to a citrix session, bit odd as we had also set up an ftp site for the wyse clients to suck their config info from but for whatever reason this was not working. Anyway as we have only had one wyse TC go pop since the remote site went live we just got on with configuring the devices.
Anyway I was over at the site recently and decided to have a real crack at sorting it out and after a bit of fiddling and a bit of googling I discovered the answer.
It basically boiled down to the fact that when the ftp server location is given to the wyse client as a dhcp option the wyse client looks for the configuration in a specific directory from the ftp root (/wyse/wnos/wnos.ini) Our wnos.ini file surfice to say was not at the location. So I created the directory structure in the ftp root and altered the wnos.ini config file rebooted a wyse tc and hey presto it begins working correctly.
This of course now brings us the complete added bonus that if another one goes bang we can tell the users to replace it with another one and it will just work the same as the old one. Brilliant eh!
Its little things like that which please me the most!
Moral of the story if you just want to deploy dhcp option 161 for the FTP site then create a /wyse/wnos folder structure so the clients can see the wnos.ini file, otherwise you will also need the 162 dhcp option to specific an alternative folder structure in an ftp site.
So since the site has been up the wyse clients have required configuring to get them to connect to a citrix session, bit odd as we had also set up an ftp site for the wyse clients to suck their config info from but for whatever reason this was not working. Anyway as we have only had one wyse TC go pop since the remote site went live we just got on with configuring the devices.
Anyway I was over at the site recently and decided to have a real crack at sorting it out and after a bit of fiddling and a bit of googling I discovered the answer.
It basically boiled down to the fact that when the ftp server location is given to the wyse client as a dhcp option the wyse client looks for the configuration in a specific directory from the ftp root (/wyse/wnos/wnos.ini) Our wnos.ini file surfice to say was not at the location. So I created the directory structure in the ftp root and altered the wnos.ini config file rebooted a wyse tc and hey presto it begins working correctly.
This of course now brings us the complete added bonus that if another one goes bang we can tell the users to replace it with another one and it will just work the same as the old one. Brilliant eh!
Its little things like that which please me the most!
Moral of the story if you just want to deploy dhcp option 161 for the FTP site then create a /wyse/wnos folder structure so the clients can see the wnos.ini file, otherwise you will also need the 162 dhcp option to specific an alternative folder structure in an ftp site.
Monday, 22 June 2009
Transcender
Well just a quick update, Transcender have kindly sent me the login details to their product, So over the next few days I shall take it for a spin and write up my thoughts on the product.
Unfortunately I have not been able to look at it sooner as I've been working all weekend and sorting something out to deal with a crow thats been bothering us. (twitterers and facebookers may already know this story).
Couple of weeks ago a crow started knocking on the windows of our house (all very amusing to start with) then he started doing it at 4am every morning(not quite so funny). Now the little blighter has taken it upon himself to pimp our cars by ripping off the wipers and ruining the rubber seals (not water based animal)around the windows by scratching them. So a week or so goes by with me jumping out of bed when I hear the crow in the vicinity and shaking my fist at him through the window (gert orf my laaarrrnnnddd)! So anyway now I need to take drastic steps to stop the black peril. Hence the purchase of a suitable tool, Just need to wait for its arrival so we can "sort him out".
Unfortunately I have not been able to look at it sooner as I've been working all weekend and sorting something out to deal with a crow thats been bothering us. (twitterers and facebookers may already know this story).
Couple of weeks ago a crow started knocking on the windows of our house (all very amusing to start with) then he started doing it at 4am every morning(not quite so funny). Now the little blighter has taken it upon himself to pimp our cars by ripping off the wipers and ruining the rubber seals (not water based animal)around the windows by scratching them. So a week or so goes by with me jumping out of bed when I hear the crow in the vicinity and shaking my fist at him through the window (gert orf my laaarrrnnnddd)! So anyway now I need to take drastic steps to stop the black peril. Hence the purchase of a suitable tool, Just need to wait for its arrival so we can "sort him out".
Monday, 15 June 2009
Transcender and wordpress
HI all,
Here's a quick post about the lovely people at transcender. They have offered me a 30 day trial of their online practice exam product to review. Well obviously I'm very keen on trying the product out and writing my experiences on the product. So thanks very much transcender.
Well today I've signed up with a wordpress account to,not to move my account you see but to use it as a backup method. I've never been too happy with all my content in one place. I'm sure that google isnt going to pull the plug on blogger without a good deal of notice but I was always rather uneasy that I didn't have any backups.
So I now use wordpresses handy dandy import tool to automagically import all my posts here and poof you have a complete backup of your blog.
Lastly I'm working on a blog about the data collector service in Xenapp which is actually very interesting I find, so hopefully there will be alot more meat appearing in the blog shortly.
Saturday, 13 June 2009
Xenapp 5 Data Collectors
Configuring the Data Collector Service
The data collector service is the hub of a citrix farm, the data collector responsibilities include but are not limited to:-
Information on published applications
Connected Users
Sessions
Licencing
Server Load
Distribution of the above Information to other data collectors in the farm.
Data collectors operate within “ZONES” inside a farm. Zones are groups of servers that are usually grouped by geographical boundaries. Zones are created to minimise WAN traffic. If for example we had offices in Iceland and one in australia, each would have a seperate zone so that users in iceland connect and lanuch published applications from the iceland zone. This would stop them connecting to the australia zone and incuring WAN costs.
In the above configuration you would still get WAN traffic however it would be minimal as only the datacollectors would be relaying information on their status to each other.
Another interesting thing about data collectors is the “election” process. This is the automated process where a data collector is elected as the primary collector and others as backups. This process is completely automated and can be explained in the following.
You have 2 zones (Iceland and Australia) each has 5 servers within their own zone (so the farm has 10 servers in total) . If all servers allowed their data collectors to chat across the WAN it would increase the amount of WAN traffic and potentially cause confusion. So within each zone the election process takes place. This allows one server to communicate the zones status/info etc to the other zome. However also elected are backup data collectors. This will then become the primary data collector should anything happen to the original primary data collector.
Although this is completely automated there are configuration settings you can change to assist the choice of the primary data collector.
MOST PREFFERED
The first choice for the data collector only assign this to ONE server in each zone. For information this is normally automatically assigned to the first xenapp server installed in a zone.
PREFERRED
The second choice for a data collector, more than one PREFFERED data collector can exist.
DEFAULT PREFERENCE
Default settings for servers, if no settings have been manually chosen for the servers then they go into this level of preference. Also in the event of a MP server failure and no manual preference settings have been configured then elections will occur at this level (simply because the PREFERRED option for a server must be manually chosen.
NOT PREFFERED
This is the runt setting for the servers. Servers in this level will only become data collectors if no others are available.
If you leave all the preference settings alone and let the farm get on with it by itself then when we installed the servers in the iceland zone the first server to come online will automatically be designated the MOST PREFFERED server, the other 4 will get the DEFAULT PREFERENCE.
The data collector service is the hub of a citrix farm, the data collector responsibilities include but are not limited to:-
Information on published applications
Connected Users
Sessions
Licencing
Server Load
Distribution of the above Information to other data collectors in the farm.
Data collectors operate within “ZONES” inside a farm. Zones are groups of servers that are usually grouped by geographical boundaries. Zones are created to minimise WAN traffic. If for example we had offices in Iceland and one in australia, each would have a seperate zone so that users in iceland connect and lanuch published applications from the iceland zone. This would stop them connecting to the australia zone and incuring WAN costs.
In the above configuration you would still get WAN traffic however it would be minimal as only the datacollectors would be relaying information on their status to each other.
Another interesting thing about data collectors is the “election” process. This is the automated process where a data collector is elected as the primary collector and others as backups. This process is completely automated and can be explained in the following.
You have 2 zones (Iceland and Australia) each has 5 servers within their own zone (so the farm has 10 servers in total) . If all servers allowed their data collectors to chat across the WAN it would increase the amount of WAN traffic and potentially cause confusion. So within each zone the election process takes place. This allows one server to communicate the zones status/info etc to the other zome. However also elected are backup data collectors. This will then become the primary data collector should anything happen to the original primary data collector.
Although this is completely automated there are configuration settings you can change to assist the choice of the primary data collector.
MOST PREFFERED
The first choice for the data collector only assign this to ONE server in each zone. For information this is normally automatically assigned to the first xenapp server installed in a zone.
PREFERRED
The second choice for a data collector, more than one PREFFERED data collector can exist.
DEFAULT PREFERENCE
Default settings for servers, if no settings have been manually chosen for the servers then they go into this level of preference. Also in the event of a MP server failure and no manual preference settings have been configured then elections will occur at this level (simply because the PREFERRED option for a server must be manually chosen.
NOT PREFFERED
This is the runt setting for the servers. Servers in this level will only become data collectors if no others are available.
If you leave all the preference settings alone and let the farm get on with it by itself then when we installed the servers in the iceland zone the first server to come online will automatically be designated the MOST PREFFERED server, the other 4 will get the DEFAULT PREFERENCE.
Friday, 12 June 2009
Publishing an Application in Citrix Xenapp 5
Publishing an application in Citrix is the act of making an application/desktop available either through the web interface or through the programme neighborhood.
There are quite a few settings to think about when publishing an application that affects not only security but performance of an application.
Applications are published to the access management console and rather than walking through the wizard clicks I will explain the various options you could choose on the way.
So once you have opened the access management console and chosen new/publish application in the application folder you will get to choose the following:-
Name
The first tab where you need to enter information is the name tab, all this requires is a friendly name and description of the app you are publishing.
Type
This tab allows you to specify what you are publishing. You can publish an application (i.e. adobe reader) , a complete desktop (good for using with thin clients) or content (i.e. web page or document).
Location
This is the file path to the applications exe or document.
Server
This allows you to select the server(s) that the application is installed on and you want users to have access too. For example a Citrix Farm consisting of 5 servers may all have adobe reader installed but for whatever reason you may only want users accessing adobe reader on 3 of the 5 servers.
Users
This is where you can specify users/groups that will have access to the published application. You can also specify to allow anonymous access which means all users will have access to the application. In real world Citrix deployments access is controlled by groups as administering individual users access to every application you publish will quickly become a nightmare.
There are quite a few settings to think about when publishing an application that affects not only security but performance of an application.
Applications are published to the access management console and rather than walking through the wizard clicks I will explain the various options you could choose on the way.
So once you have opened the access management console and chosen new/publish application in the application folder you will get to choose the following:-
Name
The first tab where you need to enter information is the name tab, all this requires is a friendly name and description of the app you are publishing.
Type
This tab allows you to specify what you are publishing. You can publish an application (i.e. adobe reader) , a complete desktop (good for using with thin clients) or content (i.e. web page or document).
Location
This is the file path to the applications exe or document.
Server
This allows you to select the server(s) that the application is installed on and you want users to have access too. For example a Citrix Farm consisting of 5 servers may all have adobe reader installed but for whatever reason you may only want users accessing adobe reader on 3 of the 5 servers.
Users
This is where you can specify users/groups that will have access to the published application. You can also specify to allow anonymous access which means all users will have access to the application. In real world Citrix deployments access is controlled by groups as administering individual users access to every application you publish will quickly become a nightmare.
Subscribe to:
Posts (Atom)
