The firewall ports that are used by an installation of Active directory can be found below:

RHEL5 rhcs cluster nodes will try to fence each other if they lose multicast cluster communications between nodes.

In these types of problems the culprit is almost always a failure or configuration issue with multicast at the network switch.
Environment
Red Hat Cluster Suite
Diagnosing the problem
1. On all cluster nodes enable recognition of icmp broadcasts:
echo 0 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

2. On all cluster nodes run "cman_tool status" and note:

A. Number of cluster nodes.
B. The cluster multicast address:

[root@node5 ~]# cman_tool status
Version: 6.1.0
Config Version: 8
Cluster Name: rhel_cluster
Cluster Id: 31412
Cluster Member: Yes
Cluster Generation: 180
Membership state: Cluster-Member
Nodes: 2
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 9
Flags: 2node Dirty
Ports Bound: 0 11 177
Node name: node5
Node ID: 5
Multicast addresses: 239.192.122.47
Node addresses: 9.47.65.165

3. Do a 2-count multicast ping:

ping -c 2 -I bond0 -b -L 239.192.122.47

4. If there are no problems then you should see multicast responses from all other cluster nodes:

PING 239.192.122.47 (239.192.122.47) from 9.47.65.165 bond0: 56(84) bytes of data.
64 bytes from 9.47.65.166: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from 9.47.65.166: icmp_seq=2 ttl=64 time=2.28 ms

-- 239.192.122.47 ping statistics --
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 1.230/1.755/2.281/0.527 ms

5. If you don't get the proper responses, then:

A. Make sure that you previously ran the following on ALL the cluster nodes:

echo 0 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

B. If you confirmed that Step 5A was done, then the either a node or network
switch is misconfigured or there are hardware problems such as bad
network cables.

6. On all cluster nodes disable recognition of icmp broadcasts:

echo 1 >/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Alternative Method

'omping' can be started on both nodes, taking the the ip of the remote node and the own ip as parameters.

Reference : How do I test multicast?

Ensure you run the same command on both nodes at the same time as mentioned in the above reference URL to properly check multicasting between the nodes.

A tale of two servers

The Apache httpd web server and the Apache Tomcat server are two very popular products in use for delivering web content.

About the Apache httpd server

The Apache httpd web server grew out of the NCSA web server. At its core, httpd implements the HTTP protocol specification. It was primarily designed to serve static files to browsers. Over the years, many features have been added and the core web server can be extended through the use of modules. Some popular modules include:

• mod_rewrite : this module provides a powerful mechanism for the administrator to rewrite URL requests that come in or get sent out of httpd
• mod_cache : this module provides a top-level module framework for caching web content
  
• mod_ssl : this module adds strong encryption to httpd using the OpenSSL toolkit
• mod_dbd : this module adds a database connectivity layer to httpd
• mod_mime : this module allows the administrator to control actions within the server based on MIME types and file extensions, it allows for the defining of handlers and filters for output

The Apache httpd web server ships with over 70 modules and there is a repository of 3rd party modules to extend it even further (currently with 490 modules.)

About the Apache Tomcat server

The Apache Tomcat server is a project that started at Sun Microsystems as the reference implementation of the Java Servlet and Java Server Pages Specifications. The Tomcat code base was donated by Sun to the Apache Software Foundation in 1999. As the Java Servlet and JSP specifications develop and mature, Tomcat's versatility grows and expands. As implied, the Tomcat server is run in a Java virtual machine and requires, at least, a JRE (Java Runtime Environment) to run although it is more commonly run using a JDK (Java Development Kit.) Tomcat should run anywhere a JDK is available (Linux, Windows, UNIX, etc.).

Tomcat also implements the HTTP protocol and can be extended to execute non-Java scripts, such as Python, PHP and Ruby.

For the remainder of the article, the Apache httpd web server will be referred to as "Apache" and the Apache Tomcat server will be referred to as "Tomcat."

The relationship between Apache and Tomcat

Both Apache and Tomcat implement the HTTP protocol for serving files to browsers. Both can be extended to serve dynamic content using many popular scripting languages. So what are the differences? Why would you choose one over the other? To answer that, let's look at the strengths.

• There is no module to allow Apache to directly execute Java code. Since Tomcat is a Java application executing in a Java virtual machine, Java becomes the native language of the web applications it serves.
  
• It can be argued that the integration of scripting languages like PHP and Python is better with Apache than with Tomcat but this isn't easily proven or refuted.
  
• Apache generally has a smaller memory footprint than Tomcat and serves static content faster using fewer resources.
  
• Virtual hosting, aliasing and URL rewriting are, generally, easier to configure in Apache.

Because of these points, people usually use Apache for supporting scripting languages and serving static content and use Tomcat for Java applications. Where they merge together is in the use of an Apache module, mod_jk for the 1.3.x and 2.0.x versions of Apache and mod_proxy_ajp for the 2.2.x version of Apache. The module allows Apache to proxy requests between the browser and a Tomcat server seamlessly through the use of a binary protocol, with persistent connections, to streamline communications, making it the preferred mechanism for connecting the two servers.

Another way to connect Apache and Tomcat is to use the mod_proxy_http module in Apache 2.2.x. This is a generic HTTP proxy and does not provide the benefits of the mod_jk/mod_proxy_ajp modules.

The combination of Apache and Tomcat provides for a powerful and scalable web server architecture

CNF objects are objects that occur in an Active Directory forest where there is a "collision" of a particular name where two different domain controllers have the same object. To ensure all objects are "unique" one of the objects gets appended with CNF followed by a GUID. In general, one of these objects should be deleted preferably the one with the older date or CNF in its name. But, either object can be valid. For more information, you an refer to the link below:

• http://www.windowsitpro.com/article/john-savills-windows-faqs/i-have-objects-in-my-active-directory-ad-domain-that-have-cnf-in-their-name-followed-by-a-globally-unique-identifier-guid-what-are-these-objects-
• http://technet.microsoft.com/en-us/library/bb727059.aspx

Back in the old days when you wanted to update a vDisk, you needed to make a complete copy of the current vDisk, then import it back into the vDisk Store, set it to Private Mode and link it to a Master device to apply your changes. After making all the changes, you needed to put the vDisk back to Standard Image mode and copy the complete vDisk to the rest of the Provisioning Services servers.

Now with Citrix Provisioning Services vDisk versioning you can add versions to your current vDisk. This method of updating the vDisk creates a delta file next to the vDisk itself. This delta file is usually considerable smaller than the complete vDisk file and you don’t need to change the vDisk mode to apply changes to it so that it can continue to be used.

My previous blog was about how to create a Citrix XenApp 6.5 vDisk. In this blog I will show you how to update this vDisk with Provisioning Services vDisk versioning and what steps you should always go through for Citrix XenApp 6.5.

Base

The first version, when creating the vDisk, is called Base (version 0). At file level, the Base consists of a .vhd file (the vDisk itself), a .pvp file (the vDisk properties file) and the .lok file (when the vDisk is in use).

Creating a vDisk version

The first step is to create a new version to the current vDisk, this will be version 1. To do that, open the Citrix Provisioning Services console, browse to the vDisk, right click on it and select Versions.

Click New

Version 1 is now created. Notice that the default access type is Maintenance. Click Done.

At file level you see that there is a *.1.avhd and a *.1.pvp file created. These are the “delta files” for Version 1, all new changes are saved in these files.

Prepare the XenApp Master server for the vDisk update

Just like when creating the vDisk, I use a dedicated XenApp Master server for updating the vDisk. This Master server has no other active user sessions and have no policies applied to it. But any server in the farm can be used to apply the updates as long as there are no active user sessions on it.

Within the Provisioning Services console open the properties of the “Master” server and change theType to Maintenance. Click OK.

Apply changes to the vDisk (version)

Make sure that the correct vDisk is linked to the XenApp “Master” server and start it.

Now that the vDisk version and the Master server are both in maintenance mode, a menu will appear at startup. Option 1 will start the server from vDisk version 1 in read/write mode. Option 2 will start the server from the base (read-only mode).

Press 1 and hit Enter

After the Master server is started, you can logon and apply the updates.

NOTE: Always reapply the steps that are needed to give certain software a unique ID or GUID as described in Step 6 AND always run the “Prepare this server for imaging and provisioning” wizard as described in Step 7 of this blog (link will be open in new window) before closing the vDisk / shutting down the master server.

After shutting down the master server, you see at file level that the *.1.avhd file has increased in size.

Test the new vDisk version (optional)

You have the ability to test the new vDisk version on different XenApp servers before promoting it to production. When promoting a vDisk version to test means also that you put it back to read-only mode, you can start multiple servers from a vDisk version in Test mode.

It is recommended to test the vDisk version on a server another then where you applied the updates. To promote the vDisk version to Test, do the following;

Open the Versions dialog of the vDisk and click on Promote. Select Test and click Ok.

Click Done

Open the properties of the Target Device you want to test de new vDisk version on and change the Type to Test. Click OK.

Now when starting the Target Device in Test mode, on startup there will be a menu appear. Option 1 will start the server from vDisk version 1 in read-only mode. Option 2 will start the server from the base.

Promote the vDisk version to production

When al tests are successful you can promote the vDisk to production (when not you can revert it back to maintenance and apply new changes). All servers assigned to this vDisk will boot the next time from the latest vDisk version with production state (until then they remain using the base version of the vDisk).

To promote the vDisk version to production, open the Versions dialog of the vDisk.

Select version 1 and click Promote.

Select Immediate or schedule the promotion for a later time. Click OK.

Click Done

If you have more than one Citrix Provisioning Services servers in your environment, don’t forget to copy the vDisk version to the other PVS servers. Check the vDisk replication status to see if all PVS servers are up-to-date.

vDisk version Merging

Each vDisk version depends on the underlying versions. For example, version 2 needs version 1 and the base to work well.

You can merge vDisk versions so that they are no longer dependent on underlying versions.

With Merging vDisk versions, you have two options;
–        Merged Updates – All updates from last base
–        Merged Base – Last base + all updates from that base

In this blog I will show you both options, starting with “Merged Updates”. For this examples I already created a second version so I can show you the difference better.

Open the vDisk Versions dialog and click Merge. Select Merged Updates and click OK

There will now be created a third version which contains both updates from version 1 and 2. This process takes a few minutes.

After a few minutes version 3 is ready.

When promoting version 3 to production, version 1 and 2 become obsolete and can be deleted safely. (Indicated by the red X)

To merge the base with all the updates, select the latest version and click Merge

Select Merged Base – Last base + all updates from that base and click OK

There will now be created a fourth version which contains the base and all updates. After a few minutes version 4 is ready.

When promoting version 4 to production, the base and version 3 become obsolete and can be deleted safely.

After deleting the base and version 3, only version 4 is left. This will be the new base. On file level you have now one big file again.

Share the post "How to update a XenApp 6.5 vDisk with Provisioning Services Versioning"

run the command below

# timedatect1 Set-ntp Yes

Command’s Used

Localect1   : command used for Keyboard layout Settings

Localect1 Status : display current lay out settings

Localect1 list-keymaps : Provides you the list of keyboard languages that are available

Localect1 List-keymaps |Grep  : command used to filter with specific list of Keyboard layout’s

localect1 Set-keymap Map : command used to set the key board layout

System Local Language Input

Command :

*********************************************************

localectl status

System Locale: LANG=en_US.UTF-8

VC Keymap: us

X11 Layout: n/a

***********************************************************

Filtering the system local by Grep like below.

localectl list-locales | g rep en_

en_AG

en_AG.utf8

en_AU

en_AU.iso88591

en_AU.utf8

en_BW

en_BW.iso88591

en_BW.utf8

output truncated

(i have posted this from a some other blog as i see it is good to read) The user logon workflow (logon process) in Storefront is different to Web Interface. The detailed description of the logon process is shown in Table 1.

Projects are often utilized as a Meaning of achieving’s strategic plan. Project typically authorized as a result of one more of the following strategic Consideration.

• Market On demand
• Strategic Opportunity
• Customer Request
• Technological advance
• Legal Requirement's

Organization manages portfolios based on their Strategic Plan, which may dictate the hierarchy to the portfolio,program and project Involved.