Ironport directory harvest for distributed deployment.

Hello everyone
We have running multiple ESAs and one SMA. The ESAs cannot access LDAP, but the SMA can. Is there a way to strengthen directory harvest protection without ESAs LDAP integration?
Thanks a lot!
Guido

No...
But there are a couple of ways to get LDAP closer to them...
I'm guessing that the ESAs are in a DMZ, and you're not letting stuff in the DMZ access the LDAP boxes, right?
Not sure if you're using Exchange, but you could put an Edge box in place, and setup Edgesync. EdgeSync uses your internal HT boxes to push out just enough AD info (eg valid email addresses) to an ADAM instance on the Edge box. You wouldn't have to feed it mail, but you could just point the ESAs at the ADAM instance for LDAP lookups...
Or you could roll your own LDAP sync somehow, using ADAM as your LDAP box in the DMZ. Or a *nix with an LDAP server on it that just has valid email addresses...

Similar Messages

Need suggestion for ISE distributed deployment model in two different data centers along with public certificate for HTTPS

Hi Experts,
I am bit confused about ISE distributed deployment model .
I have two data centers one is DC & other one is as a DR I have requirement of guest access service implementation using CWA and get public certificate for HTTPS to avoid certificate error on client devices :
how do i deploy ISE persona for HA in this two data centers
After reading cisco doc , understood that we can have two PAN ( Primary in DC & Secondary in DR ) like wise for MnT (Monitoring will be as same as PAN ) however I can have 5 PSN running in secondary i.e. in DR ISE however I have confusion about HA for PSN .. since we have all PSN in secondary , it would not work for HA if it fails
Can anybody suggest me the best deployment solution for this scenario ?
Another doubt about public certificate :
Public Certificate: The ISE domain must be a registered or part of a registered domain name on the Internet. for that I need Domain name being used from customer .
Please do correct me if I am wrong about certificate understanding :
since Guest will be the outside users , we can not use certificate from internal CA , we need to get the certificate from service provider and install the same in both the ISE servers
Can anybody explain the procedure to opt the public certificate for HTTPS from service provider ? And how do i install it in both the ISE servers ?

Hi there. Let me try answering your questions:
PSN HA: The PSNs are not configured as "primary" or "secondary" inside your ISE deployment. They are just PSN nodes as far as ISE is concerned. Instead, inside your NADs (In your case WLCs) you can specify which PSN is primary, which one is secondary, etc. You can accomplish this by:
1. Defining all PSN nodes as AAA radius servers inside the WLC
2. Then under the SSID > AAA Servers Tab, you can list the AAA servers in the order that you prefer. As a result, the WLC will always use the first server listed until that server fails/gets reloaded, etc.
3. As a result, you can have one WLC or SSID prefer PSN server A (located in primary DC) while a second WLC or SSID prefer PSN server B (located in backup DC)
Last but not the least, you could also place PSNs behind a load balancer and that way the traffic would be equally distributed between multiple PSNs. However, the PSN nodes must be Layer 2 adjacent, which is probably not the case if they are located in two different Data Centers
Certificates: Yes, you would want to get a public certificate to service the guest portal. Getting a public/well known certificate would ensure that most devices out there would trust the CA that signed your ISE certificate. For instance, VeriSign, GoDaddy, Entrust are some of the ones out there that would work just fine. On the other hand, if you use a certificate that was signed by your internal CA, then things would be fine for your internal endpoints that trust your internal CA but for any outsiders (Guests, contractors, etc) that do not trust and do not know who your internal CA is would get a certificate error when being redirected to the ISE guest portal. This in general is only a "cosmetic" issue and if the users click "continue" and add your CA as a trusted authority, the guest page would load and the session would work. However, most users out there would not feel safe to proceed and you will most likely get a lot of calls to your helpdesk :)
I hope this helps!
Thank you for rating helpful posts!

Potential Directory Harvest From Internal Host??

Hey all,
Been seeing a bunch of these messages over the past week in the logs:
Sun Apr 26 23:21:40 2009 Warning: Dropping connection due to potential Directory Harvest Attack from host=('xxxxxxxx, None), dhap_limit=1, sender_group=INVALID_DNS, listener=MailListener, reverse_dns=xxxxxxxxx, ICID 26690919
Sun Apr 26 23:21:40 2009 Info: ICID 26690919 close
Sun Apr 26 23:21:40 2009 Info: Connection Error: DCID: 2300172 domain: xxxxxxx IP: xxxxxxx port: 25 details: 550-'Too many invalid recipients' interface: xxxxxxxx reason: unexpected SMTP response
The problem is, the host is listed as the IronPort interface itself. Any idea what's going on here?

Woops. You're correct. Just forgot to include the preceding lines:
Sun Apr 26 23:21:40 2009 Info: New SMTP ICID 26690919 interface MailInterface (xx.xx.xx.126) address xx.xx.xx.126 reverse dns host unknown verified no
Sun Apr 26 23:21:40 2009 Info: ICID 26690919 ACCEPT SG INVALID_DNS match nx.domain SBRS rfc1918
Sun Apr 26 23:21:40 2009 Warning: Dropping connection due to potential Directory Harvest Attack from host=('xx.xx.xx.126', None), dhap_limit=1, sender_group=INVALID_DNS, listener=MailListener, reverse_dns=xx.xx.xx.126, ICID 26690919
Sun Apr 26 23:21:40 2009 Info: ICID 26690919 close
FYI, all XX'd out addresses are the IP address of the MailInterface.
OK, that makes more sense now. Your ESA is trying to deliver mail back to itself, reinject. Since you have no PTR its matching your INVALID_DNS sendergroup, which only allows one recipient per hour.
To find out which messages are getting reinjected, you can look for the delivery attempts.
grep "address xx.xx.xx.126" mail_logs
Should return all the delivery attempts:
Tue May 12 10:50:45 2009 Info: New SMTP DCID 42658 interface xx.xx.xx.126 address xx.xx.xx.126 port 25
Once you have a DCID, you can grep for it and get an MID
grep "DCID 42659" mail_logs
Tue May 12 11:04:45 2009 Info: New SMTP DCID 42659 interface xx.xx.xx.126 address xx.xx.xx.xx port 25
Tue May 12 11:04:45 2009 Info: Delivery start DCID 42659 MID 342967 to RID [0]
now grep for the MID and you can figure out which messages are triggering the reinjection.

Directory structure for servlets and webservices in one application

hi,
Can any one help me for creating servlets and webservices in one
application and deploying in Jboss 4.2.0.
I want to know exactly what is the directory structure for creating this
application and what are the additional .xml files for deploying this application.
if any one know this answere please tell the answere.

I figured out a solution - it's a problem of policies. In detail: Server1's codebase entry (file:) refers to the class directory of Server1's project. In the simple case of only Client1, which has no codebase entry, it works fine without a file permission on the side of Server1. In the complex case of Client1+Server2, which has to have a codebase entry (file:) refering to the class directory of the Server2's project on a separate machine, for exactly the same method call from Client1 to Server1 a file permission entry on the side of Server1 is needed for Server1's class directory. But WHY ???
It seems to be a little confusing with the codebase entries, many of the posts are contrary to others and to my personal experiences. Some comments given by Adrian Colley throw a little light upon some aspects. Is there anybody, who can explain the whole topic, when, why, and which part of RMI application deals with codebase entries, also in case of not dynamic code downloading ? May be there is also a reference into the java docs, which I didn't found up to now.
Thanks in advance
Axel

ISE NODE NOT REACHABLE when building distributed deployment

I am trying to build a distributed deployment with the following personas:
2 policy admin nodes
2 monitoring nodes
4 policy service nodes
This was a project that was partially implemented but never in production. It was in a distributed deployment, but half the nodes were no longer working (http errors or devices weren't reachable or could not sync). I decided to start from scratch. All nodes were:
-de-registered
-application was reset to factory defaults on all nodes
-upgraded all 8 nodes to 1.1.4.218 patch 1
-installed all new certs and joined all nodes to the domain
-added to DNS forward and reverse lookup zones
When I make 1 admin node primary and register the other nodes (secondary admin, monitoring, policy services) the nodes successfully register and show up in the deployment window of the primary; however, all the nodes show as NODE NOT REACHABLE. After registration, I've noticed that the registered nodes are still showing as STANDALONE if I access the GUI. I've tried rebooting them manually after registration and they are still unreachable. I have also tried resetting the database user password from the CLI on both admin nodes and the results are always the same.

Originally I had added them all at the same time. I thought that maybe I just wasn't waiting long enough for the sync. I waited an entire day and all the nodes were still unreachable. At this point, I've de-registered all the nodes, rebooted all the nodes, converted the primary back to standalone (the remaining nodes never converted from standalone to distributed even when I rebooted them after registering despite a message that they were successfully registered), converted one node back to primary and tried to register just the secondary admin node giving it plenty of time to sync; this node is still not reachable from the primary.
I've quadruple checked the certificates on all the nodes, these certs were all added on the same day (just last week) and the default self-signed certs were removed.
I had restored from a backup on the primary so I might just rest the config on that node and try joining the other nodes before I restore again.

Best practice for distributing/releasing J2EE applications.

Hi All,
We are developing a J2EE application and would like some information on the best
practices to be followed for distributing/releasing J2EE applications, in general.
In particular, the dilemma we have is centered around the generation of stub, skeleton
and additional classes for the application.
Most App. Servers can generate the required classes while deploying the EJBs in the
application i.e. at install time. While some ( BEA Weblogic and IBM Websphere are
two that we are aware of ) allow these classes to be generated before the installation
time and the .ear file containing the additional classes is the one that is uploaded.
For instance, say we have assembled the application "myapp.ear" . There are two ways
in which the classes can be generated. The first is using 'ejbc' ( assume we are
using BEA Weblogic ), which generates the stub, skeleton and additional classes for
the application and returns the file, say, "Deployable_myapp.ear" containing all
the necessary classes and files. This file is the one that is then installed. The
other option is to install the file "myapp.ear" and let the Weblogic App. server
itself, generate the required classes at the installation time.
If the first way, of 'pre-generating' the stubs is followed, does it require us to
separately generate the stubs for each versions of the App. Server that we support
? i.e. if we generate a deployable file having the required classes using the 'ejbc'
of Weblogic Ver5.1, can the same file be installed on Weblogic Ver6.1 or do we
have to generate a separate file?
If the second method, of 'install-time-generation' of stubs is used, what is the
nature/magnitude of the risk that we are taking in terms of the failure of the installation
Any links to useful resources as well as comments/suggestions will be appreciated.
TIA
Regards,
Aasif

Its much easier to distribute schema/data from an older version to a newer one than the other way around. Nearly all SQL Server deployment features supports database version upgrade, and these include the "Copy Database" wizard, BACKUP/RESTORE,
detach/attach, script generation, Microsoft Sync framework, and a few others.
EVEN if you just want to distribute schemas, you may want to distribute the entire database, and then truncate the tables to purge data.
Backing up and restoring your database is by far the most RELIABLE method of distributing it, but it may not be pratical in some cases because you'll need to generate a new backup every time a schema change occurs, but not if you already have an automated
backup/maintenance routine in your environment.
As an alternative, you can Copy Database functionality in SSMS, although it may present itself unstable in some situations, specially if you are distributing across multiple subnets and/or domains. It will also require you to purge data if/when applicable.
Another option is to detach your database, copy its files, and then attach them in both the source and destination instances. It will generate downtime for your detached databases, so there are better methods for distribution available.
And then there is the previously mentioned method of generating scripts for schema, and then using an INSERT statement or the import data wizard available in SSMS (which is very practical and implements a SSIS package internally that can be saved for repeated
executions). Works fine, not as practical as the other options, but is the best way for distributing databases when their version is being downgraded.
With all this said, there is no "best practice" for this. There are multiple features, each offering their own advantages and downfalls which allow them to align to different business requirements.

Best Practice for Distributing Databases to Customers

I did a little searching and was surprised to not find a best practice document for how to distribute Microsoft SQL Databases. With other database formats, it's common to distribute them as scripts. It seems that feature is rather limited with the built-in
tools Microsoft provides. There appear to be limits to the length of the script. We're looking to distribute a database several GBs in size. We could detach the database or provide a backup, but that has its own disadvantages by limiting what versions
of the SQL Server will accept the database.
What do you recommend and can you point me to some documentation that handles this practice?
Thank you.

Its much easier to distribute schema/data from an older version to a newer one than the other way around. Nearly all SQL Server deployment features supports database version upgrade, and these include the "Copy Database" wizard, BACKUP/RESTORE,
detach/attach, script generation, Microsoft Sync framework, and a few others.
EVEN if you just want to distribute schemas, you may want to distribute the entire database, and then truncate the tables to purge data.
Backing up and restoring your database is by far the most RELIABLE method of distributing it, but it may not be pratical in some cases because you'll need to generate a new backup every time a schema change occurs, but not if you already have an automated
backup/maintenance routine in your environment.
As an alternative, you can Copy Database functionality in SSMS, although it may present itself unstable in some situations, specially if you are distributing across multiple subnets and/or domains. It will also require you to purge data if/when applicable.
Another option is to detach your database, copy its files, and then attach them in both the source and destination instances. It will generate downtime for your detached databases, so there are better methods for distribution available.
And then there is the previously mentioned method of generating scripts for schema, and then using an INSERT statement or the import data wizard available in SSMS (which is very practical and implements a SSIS package internally that can be saved for repeated
executions). Works fine, not as practical as the other options, but is the best way for distributing databases when their version is being downgraded.
With all this said, there is no "best practice" for this. There are multiple features, each offering their own advantages and downfalls which allow them to align to different business requirements.

An EFFECTIVE development directory structure for J2EE platform?

Hi, here we r talking about deployment environment more than development
environment. Have u ever think about designing an EFFECTIVE development
directory structure for J2EE platform( e.g. weblogic )? u r not using the
deployment directories for coding, r u? :)
I used to construct a dir structure for dev and want to improve it.
d:/wholesystem/*.prj // Project files
...../module1/src/com/.... // Module source files
...../module1/doc/... // Module doc files
...../module1/classes/... // Module class files
...../module2/...
...../web/*.jsp // web page files
...../web/images/... // web page images
...../web/WEB-INF/... //...
Do u have any good ideas? Thanks!
* Name: Gary Wang
* Tele: 010-65546668-8119
* Mail: [email protected]

Create a web-inf folder at the same level of src and
jsp folder inside src
i mean
/build.xml
/src/
/src/java/<package>/...../*.java
/src/demo/<package/...../*.java
/src/test/<package>/....../*.java
/src/jsp
/web-infSo, would you put in /src/jsp only the *.jsp?
And what in /WEB-INF ? What woud you put there? Would you do something like:
/WEB-INF/web.xml
/WEB-INF/src/<package>/..../<my_servlets_and_j2ee_stuff>.java
/WEB-INF/classes/<package>/..../<my_servlets_and_j2ee_stuff>.java
In this manner sources and classes are in the same tree, it does not seem very clean to me, expecially if you consider that probably I must have a "test" directory to unit test some j2ee stuff (as for the j2se stuff in "src"): how would you do that?
Is this directory structure anyway what you meant or not?
alessio

ISE PSN rebooted and will not rejoin distributed deployment

Hi,
A PSN was powered down by accident and I'm trying to register it back to its PAN as part of a distributed deployment but I keep getting the error message "ISE not in Standalone mode".
I'm not sure how to set the PSN node back to Standalone mode when it's no longer part of the deployment.
Thanks for any help.
Barry

Hi,
Yes Deregister the PSN from the PAN after deregistration this node become Standalone node.

ISE 1.1.1 firewall rules distributed deployment

My question is in reference to the following link:
http://www.cisco.com/en/US/docs/security/ise/1.1.1/installation_guide/ise_app_e-ports.html
Basically I am struggling in some areas to work out my firewall rules for a distributed deployment. The referenced documentation is not entirely clear in my opinion. In some instances it is easy to work out what ports need to be opened eg Admin node TCP 22,80,443 for management from administrator hosts/ranges. In other instances it difficult to work out eg TCP 1521 Database listener and AQ is this for ISE nodes only or for access devices aswell
My question is whether there is a better document that details these requirements. What rules are meant to be ISE node - ISE node communications and which rules are for access device - ISE, or ISE - access device. One of the rules I am pretty confused about is the PSN CoA ports. SHould the rule be WLC - PSN on 1700 and 3799 or is it the otherway round or unidirectional?
I am pretty sure that the ports are meant to be ISE-ISE in most instances barring the PSN for Radius and CoA.

Try this for size.
In answer to the specific CoA question, I see no need for the WLC to send CoA to PSN, so just PSN to WLC as far as I can see.
You might be able to cut this list down, and you might have to add to it for any specific requirements.
From PSN to AD (potentially all AD nodes):
TCP 389, 3268, 445, 88, 464
UDP 389, 3268
From PSN to Monitoring nodes:
TCP 443
UDP 20514
PSN to Admin Nodes (2Way):
TCP 443, 1521
ICMP echo and reply (heartbeat)
WLC to PSN:
TCP 443, 8443, 80, 8080
UDP 1645, 1646, 1812, 1813, 1700, 3799, 161, 162, 9993, 67
PSN to other PSN’s (2 way)
UDP 30514, 45588, 45990
Endpoint (Laptop) to PSN (Guest laptops just need to get to external PSN’s, internal users just to internal PSN’s)
TCP 8443, 8905
UDP 8905
Admin/Sponsor to all ISE nodes:
TCP 22, 80, 443, 8080, 8443
UDP 161
PSN access to DNS servers:
TCP/UDP 53
PSN access to NTP servers:
UDP 123

Ise distributed deployment upgrade

My customer has an ISE deployment with 4 nodes: Admin/Monitor Primary and Secondary plus 2 Policy Server. The Admin nodes are VMs, the Policy nodes are 3315 appliances.
The system was installed almost three years ago with the version 1.1.0 ... It appears the system never had issues so never was patched or upgraded. Why fix something that is working fine?
Today there was an issue because the certificates expired, so in the review to get the system up and running again, the update issue bring on to the conversation. We like to do an upgrade to the last supported version. So I wonder for some tips and ideas to take care for planning the upgrade.
I have some doubts:
Can the 3315 appliance support the release 1.3 without issues?
I know the upgrade procedure is basically installing a .tar file, but I'm not clear how the process in a distributed deployment should be. I had run upgrades in standalone systems, but never in a distributed deployment. So, I need to upgrade the Primary Admin only and the other nodes would upgrade automatically?
I would need to upgrade 1.1 to 1.2 first and then 1.2 to 1.3?
I undertand release 1.1 was in 32 bits, and the version 1.2 and 1.3 are in 64 bits, so I guess the process would take a long time (perhaps a couple of hours), so a maintenance window would need 3 or 4 hours until the full system became stable.
Can you give me some advice and suggestions to avoid major issues?
Regards.
Daniel Escalante.

Can you give me some advice and suggestions to avoid major issues?
Documents related to upgarde were given by Venkatesh refer those. Along with that additional information.
Can the 3315 appliance support the release 1.3 without issues?
Cisco ISE-3315-K9 (small) 3
Supports ISE 1.3
Any
1x Xeon 2.66-GHz quad-core processor
4 GB RAM
2 x 250 GB SATA4 HDD5
4x 1 GB NIC6
I know the upgrade procedure is basically installing a .tar file, but I'm not clear how the process in a distributed deployment should be. I had run upgrades in standalone systems, but never in a distributed deployment. So, I need to upgrade the Primary Admin only and the other nodes would upgrade automatically?
When upgrading to Cisco ISE, Release 1.2, first upgrade the secondary Administration node to Release 1.2. You do not have to manually deregister the node before an upgrade. Use the application upgrade command to upgrade nodes to Release 1.2. The upgrade process deregisters the node automatically and moves it to the new deployment. If you manually deregister the node before an upgrade, ensure that you have the license file for the Primary Administration node before beginning the upgrade process. If you do not have the file on hand (if your license was installed by a Cisco partner vendor, for example), contact the Cisco Technical Assistance Center for assistance.
I would need to upgrade 1.1 to 1.2 first and then 1.2 to 1.3? I undertand release 1.1 was in 32 bits, and the version 1.2 and 1.3 are in 64 bits, so I guess the process would take a long time (perhaps a couple of hours), so a maintenance window would need 3 or 4 hours until the full system became stable
If you are on a version earlier than Cisco ISE, Release 1.2, you must first upgrade to 1.2 and then to 1.3.
You can upgrade to Cisco ISE, Release 1.2, from any of the following releases:
Cisco ISE, Release 1.1.0.665 (or 1.1.0 with the latest patch applied)
Cisco ISE, Release 1.1.1.268 (or 1.1.1 with the latest patch applied)
Cisco ISE, Release 1.1.2, with the latest patch applied
Cisco ISE, Release 1.1.3, with the latest patch applied
Cisco ISE, Release 1.1.4, with the latest patch applied
Type of Deployment
Node Persona
Time Taken for Upgrade
Standalone (2000 endpoints)
Administration, Policy Service, Monitoring
1 hour 20 minutes
Distributed (25,000 users and 250,000 endpoints)
Secondary Administration
2 hours
Monitoring
1.5 hours
After upgrading to ISE 1.2, upgrade to ISE 1.3
Type of Deployment
Node Persona
Time Taken for Upgrade
Standalone (2000 endpoints)
Administration, Policy Service, Monitoring
1 hour 20 minutes
Distributed (25,000 users and 250,000 endpoints)
Secondary Administration
2 hours
Monitoring
1.5 hours
Factors That Affect Upgrade Time
Number of endpoints in your network
Number of users and guest users in your network
Profiling service, if enabled

ISE's Internal Root CA. How to generate new one in distributed deployment?

Hello,
I have two ISE nodes in distributed deployment. I would like to generate new Internal Root CA certificate. I was able to do that from primary node, but only FOR primary node. How can I achieve this for the other node?
Best Regards,
Marek

Hi Marek-
All of the certificate management is performed from the Admin Node which becomes the Root CA for the ISE PKI. You generate Subordinate CA certificates to your Policy Nodes from the Primary Admin node. Check this link for more info:
http://www.cisco.com/c/en/us/td/docs/security/ise/1-3/admin_guide/b_ise_admin_guide_13/b_ise_admin_guide_sample_chapter_01000.html#task_FF93B4C51BAC4CA196A48B607DAA595D
Also, since the primary node is the Root CA, you should export the certificate and the private key and import it to your secondary Admin node. This will enable the secondary node to be promoted to a Root CA in case of a failure of the primary admin node:
http://www.cisco.com/c/en/us/td/docs/security/ise/1-3/admin_guide/b_ise_admin_guide_13/b_ise_admin_guide_sample_chapter_01000.html#concept_435C4E3FF56949B1B4D5A0C73671AB22
I hope this helps!
Thank you for rating helpful posts!

ISE Distributed Deployment

Hi All,
Deploying multiple PSN's with a distributed deployment, do all the PSN's have to be in the same domain? I have 8 set up in one domain, and would like to run a few more through firewalls and using a different dns domain.
Also interested to see how AD integration works with this. I'd still expect to join the nodes to the common AD domain. Would they be able to join an AD domain which isn't linked with their FQDN?
I'm hoping that running the other policy nodes on an external domain, I can use a standard CSR for the external public certs.
All comments, suggestions, spoliers welcomed! Question is out to Cisco but I know the value of these forums too.

Hi,
You will have to join all ISE nodes to the same AD domain since the policy for user enforcement (for any external conditions) is configured at the Primary Admin node and replicated down to the PSNs. However, if you choose to configure a different dns domain for one PSN and then join it to the command AD domain, the only issue I see with this is SAMAccount name being sent in the username and not the UPN.
If a user requests authentication with johndoe and your AD domain is abc.com but your dns domain is def.com, then ISE will try to authenticate [email protected] (from my experience), there have been some improvements where ISE should be able to note that this is an authentication request and should suffix the request with [email protected] but I am not 100 percent sure.
If you have a cisco account rep (with your deployment size I am absolute sure you do) have them ping the BU on this issue and see what the official response is.
Thanks,
Tarik Admani
*Please rate helpful posts*

What is the best practice for AppleScript deployment on several machines?

Hi,
I am developing some AppleScripts for my colleagues at work and I don't want to visit each of them to deploy my AppleScript on their Macs.
So, what is the best practice for AppleScript deployment on several machines?
Is there an installer created by the Automator available?
I would like to have something like an App to run which puts all my AppleScript relevant files into the right place onto a destination Mac.
Thanks in advance.
Regards,

There's really no 'right place' to put applescripts. folder action scripts nees to go in ~/Library/Scripts/Folder Action Scripts (or /Library/Scripts/Folder Action Scripts), anything you want to appear in the script menu needs to go in ~/Library/Scripts (or /Library/Scripts), script applications should probably go in the Applications folder, but otherwise scripts can be placed anywhere. conventional places to put them are in ~/Library/Scripts or in a subfolder of ~/Library/Application Support if they are run by an application. The more important issue is to make sure you generalize the scripts: use the path to command to get local paths rather than hard-coding them in, make sure you test to make sure applications or unic executables you call are present ont he machine, use script bundles rather tna scripts if you scripts have private resources.
You can write a quick installer script if you want to make sure scripts go where you want them. Skeleton verion looks like this:
set scriptsFolder to path to scripts folder from user domain
set scriptsToExport to path to resource "xxx.scpt" in directory "yyy"
tell application "Finder"
duplicate scriptsToExport to scriptsFolder with replacing
end tell
say "Scripts are installed"
save this as a script application, then open the application pacckage and create a folder called "yyy" in the resources folder and copy your script "xxx.scpt" into it. other people can run the app to install the script.

Best practices: Programming for future deployment

Hi All.. I'm starting this thread to see if I can find a consensus about the best practices for programming for future deployment of Flex apps.
Using Flex Builder, in creating a simple portal app I use "Import Web Service (WSDL)" to make the ActionScript framework for webservices which I consume. I have coded those web services in .asmx (c# web services for .NET) and run them locally. The framework Flex Builder creates is just fine, and I can run my app locally with no problem. Where I run into an issue is deployment.
My intention is to distribute the database, the .NET webservices, and the Flex app as a complete solution to my end customers.
What are the best practices in programming for complete deployability?
The main issues I'm facing:
1. Using inbuilt features like "Import Web Service (WSDL)" creates a framework around a named webservice. Upon deployment the URL for these services will change. How can you make it easy to switch the site webservices are consumed from? Can Flex apps be set up to use an environment variable, or even read a local file for the URL of the webservice I want it to point at? (i.e. something in web.config or elsewhere?)
2. Should I NOT use "Import Web Service" at all, and write the code by hand? Note: this is VERY time consuming for the number of services that are exposed in larger apps. My typical dev cycle consists of parallel updates/upgrades to web services as they are demanded by elements incorporated in the Flex app.. so it's very convenient to just re-import the WSDL as I make changes.
Thanks so much for your input!
Brian

Anyone?

Ironport directory harvest for distributed deployment.

Similar Messages

Maybe you are looking for