Follow on Twitter
Post to Twitter
When Citrix first announced NetScaler VPX at Synergy in May, we also announced that we would offer a virtual appliance for Branch Repeater that will be generally available in the first half of 2010. We want to get your input on where, when and how you will use Branch Repeater VPX.
Keep in mind that Branch Repeater is a symmetric solution which means it requires an appliance at both ends of a WAN connection. Today these must be physical appliances but with the upcoming VPX form-factor, one or both could be virtual appliances.
So when, where and how will you use a virtual Branch Repeater? Take our quick poll and then share your comments.
Branch Repeater appliances are great for providing application acceleration to your branch offices users. However, what do you do about individual remote users working from home, on the road or out of an office that is not equipped with a Branch Repeater?
Back in 2007 Citrix was one of the first companies to introduce a software-based WAN optimization client to address this need. Initially called WANScaler Client, our software client has evolved and is now called Repeater Plug-in for Citrix Receiver.
As the name implies, the client is now packaged as plug-in for Receiver for Windows. As with all plug-ins, you can use Citrix Dazzle and Citrix Merchandising Server to easily distribute the software to remote users. Once installed, the software appears as the acceleration plug-in under the "Advanced" tab within Receiver and immediately begins accelerating all application traffic.
Not using Citrix Receiver yet? Don't worry. Repeater Plug-in is available as a MSI that can run standalone without Receiver.
Repeater Plug-in for Citrix Receiver supports the same set of acceleration features as the previous WANScaler Client. This includes TCP flow control, compression and application protocol acceleration for CIFS, FTP, HTTP and now MAPI - also added in Branch Repeater 5.5. The plug-in is compatible with leading VPN solutions including Citrix Access Gateway. With Access Gateway we actually accelerate the traffic within the secure SSL tunnel. In fact, just this week we published a performance report showing how you can Turbocharge Access Gateway by up 50x. Check it out.
Over the next few weeks I will be blogging about some of the cool new features in Branch Repeater 5.5.
First up -- Exchange (MAPI) acceleration.
Everyone knows that Microsoft Exchange is the dominant enterprise email server commanding over 65% of the market. Most end users connect to their company's Exchange Server using a version of Microsoft Outlook installed on their desktop. MAPI (or Messaging Application Programming Interface) is the application layer protocol that Outlook email clients use to communicate with an Exchange Server.
As businesses have centralized their Exchange Servers in the datacenter, MAPI has become a top protocol operating over the WAN. By its nature MAPI is a "chatty" protocol which means it performs poorly in WAN environments. Branch Repeater 5.5 now automatically detects MAPI connections and responds by pipelining multiple MAPI messages together for transport across the WAN. By eliminating protocol chattiness, Branch Repeater makes Outlook/Exchange significantly faster over high latency connections.
Large email attachments are another cause of poor email performance. Branch Repeater addresses this issue by automatically compressing and de-duplicating email attachments.
The results are nothing short of stunning. In many cases you will see performance improvements of 10, 20 or even 50x.
Beyond accelerating the end-user experience, this feature also has a dramatic impact on reducing network bandwidth consumption. Imagine a user in a branch office emailing a 10MB attachment to ten other people in that office. Without Branch Repeater, the entire 10MB file must be transmitted to the Exchange Server and then transmitted back to the branch office ten times - once for each recipient. With Branch Repeater, the attachment is only transmitted across the WAN once.
Branch Repeater's Exchange (MAPI) acceleration is not just for branch offices. The Repeater Plug-in for Citrix Receiver brings this functionality to individual remote users working from home or on the road. Now you don't have to wait forever to download that large attachment while working in your hotel room.
Earlier I said that most users connect to their company's Exchange server using a locally installed version of Outlook. That makes sense since many users need offline access to their email. But wait a minute... XenApp also provides offline access to applications with application streaming. And guess what? A streamed version of Outlook talks MAPI too. So whether you have locally installed Outlook clients or are streaming Outlook with XenApp -- you need to try out Branch Repeater 5.5 in your network.
Secure Selected Pages
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
In situations where you want to make sure that for some selected pages only the secure server is used, the following can be used.
Apache rewrite:
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/?(page1|page2|page3|page4|page5)$ https://www.example.com/%1 [R,L]
AppExpert rewrite example 1:
Add responder action res_redirect redirect '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.REGEX_MATCH(re/page[1-5]/)' res_redirect
Bind responder global pol_redirect 100 END
AppExpert rewrite example 2:
Add patset pat1 Bind patset pat1 page1 Bind patset pat1 page2 Bind patset pat1 page3 Bind patset pat1 page4 Bind patset pat1 page5 Add responder action res_redirect redirect '"https://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes Add responder policy pol_redirect '!CLIENT.TCP.DSTPORT.EQ(443)&&HTTP.REQ.URL.CONTAINS_ANY("pat1")' res_redirect Bind responder global pol_redirect 100 END
Tap into the power of AppExpert!
Redirecting a URI to a new format
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Let's say, for example, that you've got a set of working URLs that look like this: /index.php?id=nnnn. However, you'd really like to change them to /nnnn and make sure search engines update their indexes to the new URI format. First, you'd have to redirect the old URIs to the new ones so that search engines update their indexes, but you still have to rewrite the new URI back to the old one so that the index.php script would run.
Example: The trick here is to place into the query string a marker code that will not be seen by visitors. We redirect from the old link to the new format only if the "marker" is not present in the query string. Then we rewrite the new format link back to the old format, and add a marker to the query string.
Apache rewrite:
RewriteCond %{QUERY_STRING} !marker
RewriteCond %{QUERY_STRING} id=([-a-zA-Z0-9_+]+)
RewriteRule ^/?index\.php$ %1? [R,L]
RewriteRule ^/?([-a-zA-Z0-9_+]+)$ index.php?marker&id=$1 [L]
AppExpert rewrite:
Add responder action act_redirect redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("index.php")+HTTP.REQ.URL.QUERY.VALUE("id")' -bypassSafetyCheck yes Add responder policy pol_redirect '!HTTP.REQ.URL.QUERY.CONTAINS("marker")&& HTTP.REQ.URL.QUERY.VALUE("id").REGEX_MATCH(re/[-a-zA-Z0-9_+]+/) && HTTP.REQ.URL.PATH.CONTAINS("index.php")' act_redirect Bind responder global pol_redirect 100 END Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"index.phpmarker&id="+HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' -bypassSafetyCheck yes Add rewrite policy pol1 '!HTTP.REQ.URL.QUERY.CONTAINS("marker")' act1 Bind rewrite global pol1 100 END
Tap into the power of AppExpert!
Creating Extensionless links
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Sometimes you may want to support extension less links, either to hide extensions from end users or to make URLs easy to remember.
Example 1: add .php extension to all requests
Apache rewrite:
RewriteRule ^/?([a-z]+)$ $1.php [L]
AppExpert rewrite:
Add rewrite action act1 insert_after 'HTTP.REQ.URL' '".php"'
Add rewrite policy pol1 'HTTP.REQ.URL.PATH.REGEX_MATCH(re#^/([a-z]+)$#)' act1
Bind rewrite global pol1 100
Example 2: if we have a mixture of both .html and .php files, the following can be used
Apache rewrite:
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.php [L]
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^/?([a-zA-Z0-9]+)$ $1.html [L]
AppExpert rewrite:
Here HTTPCallout would be used, script file_check.cgi hosted on 10.102.59.101 is used to check wether provided argument is avalid file name or not.
add HTTPCallout Call_html add HTTPCallout Call_php set policy httpCallout Call_html -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url+".html" set policy httpCallout Call_php -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url+".php" Add patset pat1 Bind patset pat1 .html Bind patset pat1 .php Bind patset pat1 .asp Bind patset pat1 .cgi Add rewrite action act1 insert_after 'HTTP.REQ.URL.PATH' '".html"' Add rewrite action act2 insert_after "HTTP.REQ.URL.PATH" '".php"' Add rewrite policy pol1 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_html)' act1 Add rewrite policy pol2 '!HTTP.REQ.URL.CONTAINS_ANY("pat1") && SYS.HTTP_CALLOUT(Call_php)' act2 Bind rewrite global pol1 100 END Bind rewrite global pol2 101 END
Tap into the power of AppExpert!
Blocking Inline Images
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume you have under http://www.quux-corp.de/~quux/ some pages with in lined GIF graphics. These graphics are nice, so others directly incorporate them via hyperlinks to their pages. you don't like this practice because it adds useless traffic to your server.
Example : You can restrict the cases where the browser sends a HTTP Referer header.
Apache rewrite:
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$
RewriteRule .*\.gif$ - [F]
AppExpert rewrite:
Add patset pat1 Bind patset pat1 .gif Bind patset pat1 .jpeg add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"' add responder policy pol1 '!HTTP.REQ.HEADER("Referer").EQ("") && !HTTP.REQ.HEADER("Referer").STARTSWITH("http://www.quux-corp.de/~quux/")&&HTTP.REQ.URL.ENDSWITH_ANY("pat1")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Blocking Robots
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
You can block a really annoying robot from retrieving pages of a specific webarea. This way you can ease up the traffic at some directories.
Example : This could be done by using a rule set which forbids the URLs of the web area /~quux/foo/arc/. This could also be accomplished by matching the User-Agent HTTP header information. In this example, the ip address to be blocked is 123.45.67.8 & 123.45.67.9.
Apache rewrite:
RewriteCond %{HTTP_USER_AGENT} ^NameOfBadRobot.*
RewriteCond %{REMOTE_ADDR} ^123\.45\.67\.[8-9]$
RewriteRule ^/~quux/foo/arc/.+ - [F]
AppExpert rewrite:
add responder action act1 respondwith '"HTTP/1.1 403 Forbidden\r\n\r\n"' add responder policy pol1 'HTTP.REQ.HEADER("User_Agent").STARTSWITH("NameOfBadRobot")&&CLIENT.IP.SRC.EQ(123.45.67.8)&&CLIENT.IP.SRC.EQ(123.45.67.9) && HTTP.REQ.URL.STARTSWITH("/~quux/foo/arc")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Browser Dependent Content
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
At least for important top-level pages it is sometimes necessary to provide the optimum of browser dependent content, i.e. one has to provide a maximum version for the latest Netscape variants, a minimum version for the Lynx browsers and an average feature version for all others.
Example : We will act on the HTTP header "User-Agent". The following config does the following: If the HTTP header "User-Agent" begins with "Mozilla/3", the page foo.html is rewritten to foo.NS.html and the rewriting stops. If the browser is "Lynx" or "Mozilla" of version 1 or 2 the URL becomes foo.20.html. All other browsers receive page foo.32.html. This is done by the following rule set:
Apache rewrite:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.*
RewriteRule ^foo\.html$ foo.NS.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx/.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[12].*
RewriteRule ^foo\.html$ foo.20.html [L]
RewriteRule ^foo\.html$ foo.32.html [L]
AppExpert rewrite:
Add patset pat1 Bind patset pat1 Mozilla/1 Bind Patset pat1 Mozilla/2 Bind patset pat1 Lynx Bind Patset pat1 Mozilla/3 add rewrite action act1 insert_before 'HTTP.REQ.URL.SUFFIX' '"NS."' add rewrite action act2 insert_before 'HTTP.REQ.URL.SUFFIX' '"20."' add rewrite action act3 insert_before 'HTTP.REQ.URL.SUFFIX' '"32."' add rewrite policy pol1 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").EQ(4)' act1 add rewrite policy pol2 'HTTP.REQ.HEADER("User-Agent").STARTSWITH_INDEX("pat1").BETWEEN(1,3)' act2 add rewrite policy pol3 '!HTTP.REQ.HEADER("User-Agent").STARTSWITH_ANY("pat1")' act3 bind rewrite global pol1 101 END bind rewrite global pol2 102 END bind rewrite global pol3 103 END
Tap into the power of AppExpert!
Old to New External URL Rewrite
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume that you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. But this time you want the users of the old URL to see new one, i.e. their browsers Location field should change too.
Example : The following rules can force an HTTP redirect to the new URL which leads to a change of the URL in the users browser:
Apache rewrite:
RewriteEngine on RewriteBase /~quux/ RewriteRule ^foo\.html$ bar.html [R]
AppExpert rewrite: (There are two ways to do this)
add responder action act1 redirect 'HTTP.REQ.URL.BEFORE_STR("foo.html")+"bar.html"' -bypassSafetyCheck yes add responder policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1 bind responder global pol1 100
add responder action act1 redirect 'HTTP.REQ.URL.PATH.BEFORE_STR("foo.html")+"bar.html"+HTTP.REQ.URL.AFTER_STR("foo.html")' -bypassSafetyCheck yes add responder policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Old to New Internal URL Rewrite
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Assume you have recently renamed the page foo.html to bar.html and now want to provide the old URL for backward compatibility. Actually you want users of the old URL to not recognize that the pages were renamed.
Example : Rewrite the old URL to the new one internally via the following rule, let the base directory be /~quux/.
Apache rewrite:
RewriteEngine on RewriteBase /~quux/ RewriteRule ^foo\.html$ bar.html
AppExpert rewrite: (There are two ways to do this)
add rewrite action act1 replace 'HTTP.REQ.URL.AFTER_STR("/~quux").SUBSTR("foo.html")' '"bar.html"' add rewrite policy pol1 'HTTP.REQ.URL.ENDSWITH("/~quux/foo.html")' act1 bind rewrite global pol1 100
Add rewrite action act1 replace 'HTTP.REQ.URL.PATH.SUFFIX(\'/\',0)' '"bar.html"' Add rewrite policy pol1 'HTTP.REQ.URL.PATH.CONTAINS("foo.html")' act1 Bind rewrite global pol1 100
Tap into the power of AppExpert!
Time Dependent Rewriting
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
We can rewrite a URL based on time.
Example : Changing the request foo.html to foo.day.html or foo.night.html according to time.
Apache rewrite:
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.day.html [L]
RewriteRule ^foo\.html$ foo.night.html
AppExpert rewrite:
Add rewrite action act1 insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"day."' Add rewrite action act2 insert_before 'HTTP.REQ.URL.PATH.SUFFIX(\'.\',0)' '"night."' add rewrite policy pol1 'SYS.TIME.WITHIN(LOCAL 07h 00m,LOCAL 18h 59m)' act1 add rewrite policy pol2 'true' act2 bind rewrite global pol1 101 bind rewrite global pol2 102
Tap into the power of AppExpert!
Failed URL Redirect
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
In case the current url is not valid & the request needs to be redirected to another web server, the following steps could be taken.
Example : We will check weather the request filename exists on the server or not, in case it fails then redirection is done to another webserver (for example, webServerB.com). In the case of AppExpert, HTTPCallout is used to check the presence of the file on the server by running a script file_check.cgi on the server. The returned value from HTTPCallout is used to validate the policy.
The Script file_check.cgi takes the url as the argument, checks for its presence on the server & returns True or False accordingly.
Apache rewrite:
RewriteCond /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule ^(.+) http://webserverB.com/$1 [R]
AppExpert rewrite: (There are two ways to do this)
add HTTPCallout Call set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url.path -headers Name("ddd") add responder action act1 redirect '"http://webserverB.com"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS && !SYS.HTTP_CALLOUT(call)' act1 bind responder global pol1 100
add HTTPCallout Call set policy httpCallout Call -IPAddress 10.102.59.101 -port 80 -hostExpr '"10.102.59.101"' -returnType BOOL -ResultExpr 'HTTP.RES.BODY(100).CONTAINS("True")' -urlStemExpr '"/cgi-bin/file_check.cgi"' -parameters query=http.req.url.path -headers Name("ddd") add responder action act1 respondwith '"HTTP/1.1 302 Moved Temporarily\r\nLocation: http://webserverB.com"+HTTP.REQ.URL+"\r\n\r\nHTTPCallout Used"' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HEADER("Name").EXISTS && !SYS.HTTP_CALLOUT(call)' act1 bind responder global pol1 100
Tap into the power of AppExpert!
Structured Homedirs
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
Some sites with thousands of users usually use a structured homedir layout, i.e. each homedir is in a subdirectory which begins for instance with the first character of the username. So, /~foo/anypath is /home/f/foo/.www/anypath while /~bar/anypath is /home/b/bar/.www/anypath.Following rules could be used to implement this.
Apache rewrite:
RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/.www$3
AppExpert rewrite:
Add rewrite action act1 replace 'HTTP.REQ.URL' '"/home/"+ HTTP.REQ.URL.AFTER_STR("~").PREFIX(1)+"/"+ HTTP.REQ.URL.AFTER_STR("~").BEFORE_STR("/")+"/.www"+HTTP.REQ.URL.SKIP(\'/\',1)' -bypassSafetyCheck yes Add rewrite policy pol1 'HTTP.REQ.URL.PATH.STARTSWITH("/~")' act1 Bind rewrite global pol1 100
Tap into the power of AppExpert!
Move Homedirs to Different Web Server
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
There are cases when you want to redirect requests for homedirs on one web server to another web server. The typical use case for this arises when establishing a newer web server which will replace the old one over time. i.e. you need to redirect all the requests for a particular homedir to another web server.
Example : Let the hostname for new webserver be newserver.
Apache rewrite:
RewriteRule ^/(.+) http://newserver/$1 [R,L]
AppExpert rewrite: (There are two ways to do this)
Add responder action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.REGEX_MATCH(re#^/(.+)#)' act1
Bind responder global pol1 100 END
Add responder action act1 redirect '"http://newserver"+HTTP.REQ.URL' -bypassSafetyCheck yes
Add responder policy pol1 'HTTP.REQ.URL.LENGTH.GT(1)' act1
Bind responder global pol1 100 END
Tap into the power of AppExpert!
Load Balancing Auto-Configuration for SAP using Workflow Studio and NetScaler
At the tail end of our certification process at SAP, Citrix engaged in a unique opportunity to make use of the SAP APIs, using Workflow Studio to auto-configure the Citrix NetScaler for Load Balancing. The way it works is, Workflow Studio polls the SAP API, reads the response, and then based on the results in the response, configures the NetScaler Load Balancing groups that map directly to the SAP servers running in the server farm.
SAP has a community group dedicated to the development of their APIs, please reference the latest blog post Catching Up with Deployment and Operations Automation, describes the SAP APIs.
The SAP Community Definition Group (CDG) - titled "PCDG 97 NetWeaver Infrastructure APIs for Network Solutions" - is focused on automation of network-application integrated configuration and operation. As the group title implies, the SAP NetWeaver technology platform includes APIs, which are used by the NetScaler ADCs (load balancers) to auto-configure themselves as proxies for multi-instance SAP application systems. Using Citrix Workflow Studio, the SAP APIs are polled on a regular basis so that the NetScaler ADCs can react to SAP application instance changes during production runtime.
If another application instance is brought up, let's say for providing more computing capacity for an increasing end-user load, or if an instance is brought down temporarily for maintenance, Workflow Studio communicates with the NetScaler ADC to adjust load balancing automatically without any manual administrator intervention. There is no more wait, or lengthy change management required to provision applications.
Workflow Studio, NetScaler and SAP API Use Cases:
Use Case 1: (auto-configure new SAP services).
Workflow Studio sends a URL request to the SAP Message Server, and receives a response. Workflow Studio parse's the response, looking for specific SAP generated patterns. WFS then uses this information to configure a Load Balancing Virtual Server inside of the Citrix NetScaler.
Use Case 2: (dynamic configuration).
Workflow Studio repeatedly queries the SAP API. WFS studio can determine hostnames, ip addresses, port numbers, and whether an SAP server is coming online or going down. When a SAP server comes online/goes down - WFS detects this change, and then takes action on the Citrix NetScaler, to add/remove the SAP service from the Load Balancing group - automatically.
Use Case 3: (graceful shutdown).
Workflow Studio queries the SAP API, determines a SAP server is going down, and based on the response, waits until all existing sessions have been retired, before removing the server from the Load Balancing group . During the shutdown period, no new sessions are added to that SAP server, providing a graceful shutdown of the SAP service. This way, there are no TCP resets sent to existing sessions. New logins are routed to a different server.
Read the SAP article here.
Tap into the power of AppExpert!
Canonical Hostnames
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler.
The goal of the following rule is to force the use of a particular hostname, in preference to other hostnames which may be used to reach the same site. For example, if you wish to force the use of www.example.com instead of example.com, you might use a variant of the following rules.
Example : changing example.com to www.example.com
Apache rewrite:
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*) http://www.example.com:%{SERVER_PORT}/$1 [L,R]
RewriteCond %{HTTP_HOST} !^www.example.com
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://www.example.com/$1 [L,R]
AppExpert rewrite:
add responder action act1 redirect '"http://www.example.com:"+CLIENT.TCP.DSTPORT+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&!HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
add responder action act1 redirect '"http://www.example.com"+HTTP.REQ.URL' -bypassSafetyCheck yes add responder policy pol1 '!HTTP.REQ.HOSTNAME.CONTAINS("www.example.com")&&!HTTP.REQ.HOSTNAME.EQ("")&&HTTP.REQ.HOSTNAME.PORT.EQ(80)&&HTTP.REQ.HOSTNAME.CONTAINS("example.com")' act1 bind responder global pol1 100 END
Tap into the power of AppExpert!
Canonical URLs
The Citrix NetScaler can be placed in front of a webserver farm that is running Apache. The same re-write rules that run on Apache, can be implemented on the Citrix NetScaler. On some Apache web servers there is more than one URL for a resource. Usually there are canonical URLs (which should be used and distributed as a best practive) and those which are just shortcuts, internal ones, etc. Independent of which URL was supplied with the request, the user should only see the canonical one URL in the response.
Example : converting URL /~user to /u/user.
Apache rewrite:
RewriteRule ^/~([^/]+)/?(.*) /u/$1/$2[R]
AppExpert rewrite:
Add responder action act1 redirect '"/u/"+HTTP.REQ.URL.AFTER_STR("/~")' -bypassSafetyCheck yes Add responder policy pol1 'HTTP.REQ.URL.STARTSWITH("/~") && HTTP.REQ.URL.LENGTH.GT(2)' act1 Bind responder global pol1 100
Tap into the power of AppExpert!
SAP certifies NetScaler v9.0 and Branch Repeater/WANScaler v4.5 solution
On 3/31/2009, SAP certified Citrix NetScaler v9.0 and Citrix Branch Repeater/WANScaler v4.5 as an integral solution to improve the delivery of the SAP applications. For SAP Portal, the Citrix NetScaler & Branch Repeater/WANScaler solution improved response time to clients. For downloads and backend operations from SAP Composite and ERP servers, response time was also improved.
SAP customers have hundreds of branch offices with a mixture of small and large offices, and a global distribution. It is important to have a solution which optimizes, simplifies and accelerates the delivery of the SAP applications. During certification testing it was proven that the NetScaler and Branch Repeater/WANScaler products improve performance of SAP applications through acceleration, provide security through HTTPS connections, and provide reliability & high availability through load balancing.
Read more about NetScaler here.
Read more about Branch Repeater/WANScaler here.
Tap into the power of AppExpert!
Have you been hearing about the new Citrix HDX Technologies? Have you heard that HDX enables branch office users to get that "high definition" XenApp experience? Are you still trying to figure out what this all really means?
Recently there has been a lot of new terminology, concepts, news, and capabilities for Citrix Branch Repeater to take in. One of the most exciting topics has been around multi-user XenApp optimization for branch office users with Citrix HDX Broadcast and HDX IntelliCache. Spend some time getting caught up to speed on all these great happenings by reading a new whitepaper titled "Understanding Citrix HDX Technology for Optimizing the Branch Office".
This whitepaper will enable you to speak like a HDX branch office guru as you learn about:
- What is driving branch offices to virtualize their applications
- What are branch offices doing about the WAN
- What Citrix Branch Repeater does for XenApp
- How HDX Broadcast and HDX IntelliCache deliver a high-def branch experience
The whitepaper (CTX120455) is available for download on the Branch Repeater section of the Citrix Knowledge Center.