2009

ANSA Miscellaneous Technical FAQ

Autonomic Software November 2009

Autonomic Software Documentation Form 210-00002 2009 Copyright 2007 Autonomic Software, Inc. All rights reserved. Printed in the United States of America. The information in this manual has been checked carefully and is believed to be accurate; however, Autonomic Software assumes no responsibility for possible inaccuracies or omissions. Specifications are subject to change without notice. Microsoft, MS-DOS, VBScript, Visual Basic, Visual C++, C#, .Net Framework and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and other countries. Linux is a registered trademark of Linus Torvalds. All other brand or product names are trademarks or registered trademarks of their respective companies or organizations. Within this document, the names ANSA and Autonomic Software will be interchanged freely.

Miscellaneous Technical FAQ

What is the communication protocol (e.g. http, TCP) The communication protocol uses HTTPS and TCP/IP. Connection to get patches, scan definitions, to view the repository through the user interface, and registration to our GUR database uses HTTPS Connection to/from the controller/agent uses TCP (ports 9311 and 9312) and is encrypted. What is the security model of the communication (i.e. how is authentication and authorization done and is the messaging encrypted) The agent and controller communication through IP addresses and port numbers (9311 and 9312). The agent is identified by the controller from a generated ID # that is part of the MAC address of the client computer. This information is contained in a controller's "config.xml" file (xml file) and an agent's "config.xml" (xml file). Additionally, it is all stored in the database too. The agent knows communication is only coming from and directly from the ANSA controller because they have already established their communication through IP address and port #. Additionally, the controller knows it is communicating with the correct agent based on the ID # (the agent's ID is generated upon installing the agent software and remember, the ID holds the MAC address of the client's NIC). All their communication is encrypted. In patch management, do you currently have following capabilities? Formalized staging and testing workflows: At Autonomic Software, our IT team and developer work to test the patches in various computer environments before releasing the patch to the customer. We follow directive from Microsoft on what operating system the patch applies to. Once we have updated our scan-definitions, we test the patch to make sure the proper files in the operating system are being altered (what Microsoft says is being altered compared to log files that the patch actual makes once installed). We test for reboot or no-reboot options. If the patch applies to a certain version of a product (like IE 5.01 or 6.0 with no service pack), we will test the patch in that environment and others to see how the patch behaves. Selective or comprehensive patch rollback workflow: We are currently working on a rollback feature that will be built into the user interface. This feature should be released with our next major release of the software. A release date has not been set yet, but I would overly state and say less than 3 months. Any patch related problem feedback/tracking/resolution workflows: We receive feedback from customers regarding any patch discrepancies and note them in a database we store internally. We do not allow public access to this database. We are currently working on a customer portal web site that will have a feature in it that will allow customers to view patches issues, resolutions and provide written feedback that can be submitted to the customer portal.

In asset management, what are the user configuration options on data to be collected? Please see the ANSA Asset Information Document that outlines all the asset information ANSA Collects. What are the user configuration options on how the collected data is displayed in the UI? The data is all stored in the ANSA database. It is displayed in the through pre-configured stored procedures that are executed when you click a certain link in the UI. Additionally, the UI offers, in terms of user configuration, the default "admin" user which has full access and rights to the UI, guest users which are assigned to groups of computers with limited capabilities that only apply to those computers in their assigned group, and a "reporter" user which is limited in their abilities to only produce reports. What data collection methods are used in different OS platforms? For every OS, the data collection method is the same. Each agent (for Windows, Mac, Linux, and Solaris) has an executable file that effectively scans the client machine gathering the client computer information. This information is then stored in an xml file and transmitted back to the controller. The controller receives that information and passes onto the database where it is eventually stored for good. Once the user is in the UI, they will be able to view the client computer details. It was mentioned that a maximum 2,000 agents is recommended per controller. What are the determining factors of limiting to 2,000 agents? In theory, you could have more than 2,000 agents per controller. In practice, we recommend no more than 2000 agents per controller due to overloading the computer. In communicating with customers, we have noticed that many do not have computers with more than 2+GB of RAM (if they do, they are not using the ANSA on it as those computers would probably be serving another function in their organization already). With having an average of 1GB to 2GB of RAM and having 2000 agents instantly would produce a lot of strain on the server (controller computer) itself. However, due to advancements in communication to/from the agent/controller, one could have more than 2000 agents - we recommend 2000 or less to customers for their sake to reduce strain upon the computer. Also in communication with customers, we note that most customers use their ANSA server for other functions as well. Additionally, they might be using their SQL database for other database functions and jut adding the ANSA database to their entire DBMS. Although SQL is robust enough to handle a huge workload, the computer itself is still being strained. For example, let us assume you have 2000 agents deployed and they are all displayed on your user interface. You would only see strain on the computer if you process Report Inventory for all agents at the same time - or did update scan definitions, clean scan or restart all agents at the same time. In practice, we rarely see customers do such. Customers will usually put computers in groups and do updates and maintenance group by group to produce less strain on the computer and for easier organization.

What is the bandwidth control mechanism in agent communication? Our software does not control the bandwidth in your network; however, our software does to bandwidth provisioning. Basically, the only bandwidth our software uses is when the agent and controller are communicating, when the controller communicates with the database, or when the controller is communicating with our global update repository computer (via the Internet). When they are not communicating, there is no bandwidth usage at all. Depending upon your network structure and type, which will determine the network bandwidth (token ring, peer to peer, 10/100 vs. gigabit, etc). One thing that should be taken into consideration is the patch sizes. Most patches are relatively small in size (under 3MB). A file of 3MB or smaller poses no significance to bandwidth usage. If you are downloading a service pack though (which can range from 200mb to 350mb) and pushing it across your network to several machines at once will be noticed by the network, but will not bring the network to a halt. In testing bandwidth usage pushing service packs across the network on a 10/100 network, I have noticed that a maximum of 10% usage is recorded.

When deploying an agent on Windows XP and you receive the error: Network Path Could Not Be Found: Make sure NetBIOS is enabled (i.e. NetBIOS over IP (NetBT/WINS), NetBIOS over IPX, etc...). Turn on NetBIOS over TCP/IP: 1. Click Start, click Control Panel, and then click Network and Internet Connections. 2. Click Network Connections. 3. Right-click Local Area Connection, and then click Properties. 4. Click Internet Protocol (TCP/IP), and then click Properties. 5. Click the General tab, and then click Advanced. 6. Click the WINS tab. 7. Under NetBIOS setting, click Enable NetBIOS over TCP/IP, and then click OK two times. 8. Click Close to close the Local Area Connection Properties dialog box. 9. Close the Network Connections window. (Taken from: http://support.microsoft.com/?kbid=318030)

You should easily be able to duplicate this issue outside of our software by attempting to map a drive to a shared resource on the remote machine (i.e. Net use X: \\HostName\Admin$ or X: \\IP-Address\Admin$ [from a command line]). This can be done to map a drive, or you can simply try from a RUN command: \\IP-Address\C$ or Admin$ \\HostName\C$ or Admin$

Please also verify that File & Printer Sharing is installed on the remote machine. Also, if the remote machine is on a different subnet, please also keep in mind that all the necessary "File & Printer Sharing" ports must also be open on the routers/firewalls between the machines for file/print sharing to work.

If you are using Windows XP Service Pack and the firewall is ON & your computers are in a domain, read this article: Managing Windows XP Service Pack 2 Features Using Group Policy: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngwfw.mspx You can also deploy this script through your domain to configure the XP SP2 firewall to allow an exception: Netsh firewall add allowedprogram program=c:\ansa\agent\ansa.exe name=ansa mode=enable scope=all profile=all If you think you are having a problem related to DNS and caching, you can flush the DNS. At a command prompt, type the following command, and then press ENTER: Ipconfig /flushdns

I am unable to get agent to connect to controller. In most cases, the agents config.xml file does not have the correct server IP address in the local address section: (From the agent config.xml)

<interface-accept> <local addr="any" port="9312" /> </interface-accept> <interface-connect> <local addr="any" port="any" /> <remote addr="0.0.0.0" port="9311" /> </interface-connect>
Replace the 0.0.0.0 with the ANSA Server IP Address (or computer name). Do not change the port #s.

Also: (in the package module section second section of the file)

<interface-connect> <local addr="any" port="9311"/> <remote addr="0.0.0.0" port="9312"/> </interface-connect>

The line <local addr= should be any on port 9311 <remote addr= replace 0.0.0.0 with your server IP address on port 9312 (From the controller config.xml)

<interface-accept> <local addr="Put Server IP Here" port="9311" />

Also: (in the packaged module section second section of the controller config.xml file)

<interface-accept> <local addr="0.0.0.0" port="9312"/> </interface-accept>

The <local addr= Replace the 0.0.0.0 with your Server IP address on port 9312 Verify that these two files of the xml code have the same IP address. Also, note the port numbers. If you have a firewall running, open Ports 9311, 9312, and 9313 (or whatever ports you use for the agent/controller in the config.xml files).

Q & A: Q: I have quite a mix of computers on my network, and I am not sure of the OS versions, application, etc. How will ANSA be deployed? A: Our engineers will provide you with a questionnaire prior to installation of the ANSA suite of products. Once these determinations are made, it is easy to deploy the application throughout your network. Q: When deploying custom packages, can I send out software packages as well as patches. A: Yes. For ANSA, anything that can be made executable (exe, bat, jobstreams, etc) can be deployed as a custom patch. This means software packages (new installs) as well as one-time password changes can be deployed to any set of clients on the network. It is simply a matter of creating the executable or stream of commands, defining it to ANSA, and deploying it via the scheduling process. Q: We want to be able to test patches in a small subset of our network. How does ANSA allow this? A: ANSA will allow you to define a separate Inoculation Server, which actively deploys patches to your small subset of clients. Additionally, you could set up a separate test group (by using grouping functionality within the user interface) which will allow you to create a subset to which you can direct specific actions (patch deployment, asset scanning, etc). In this way, you can control how and when patches are deployed based on your organizations needs. Q: I discovered a patch, which when it was installed, caused a problem with one of our homegrown applications. What can I do? A: Since the vast majority of Microsoft patches, in addition to patch installation, provide for removal of that same patch, ANSA will allow the uninstall package to be deployed across your network. For other operating systems, assuming an uninstall mechanism is available, ANSA can be utilized to deploy the uninstall package. Q: While a patch was being installed, one of my users shut down the desktop, halting installation of the patch. What will happen? A: The ANSA client, next time the machine is connected to the network, will attempt to install the patch until it is successful in doing so. If the patch, based on progress, has failed, it will be inserted in the failed queue where it can be redeployed from through the common scheduling mechanism. Q: We would like to have critical patches tested before we get them. Does ANSA provide for this? A: Yes. The Professional Services branch of ANSA can replicate your environment and test patches prior to releasing them to your organization. We will mirror your environment to the extent you feel necessary, as well as testing any patches to that same extent before releasing them to your system administrators. Q: I am concerned about the timely deployment of patches within our organization. How does ANSA address this concern? A: ANSA guarantees that any patches made available from Microsoft are available to its users within 12 hours of that release, assuming no custom testing is necessary. For other vendors, ANSA will turn around all available public patches within that same period (12 hours). As a hosted solution, ANSA retains permanent staff to constantly oversee and maintain the Global Update Repository, which is the source from which patches are ultimately deployed to all ANSA users. Once the patches are made available to ANSA users, it is the responsibility of the system administrators to deploy them via the ANSA framework provided.

Q: How large is the ANSA agent that will reside on each of my client computers? A: The footprint of the ANSA client agent is approximately 4MB-12MB. When asked to, the agent will expand and contract, depending on functionality invoked. Example: when scanning the agent machine, the agent itself may expand to up to 12 megabytes; when done, it will contract back down to dormant mode size (this entire process will take less than 1 minute in most cases). Q: Occasionally, a user will update software or otherwise change the environment on their desktop or laptop machine. Because of this, if a patch is negated on that machine, will ANSA recognize this condition? A: Yes, the next time the agent logs onto the network, the ANSA server will know that the agent has become out of sync with the server. The agent will scan it (based on policy) and the ANSA console will show the patch has become available for the agent machine. Remote Deploy FAQ: My Remote Deploy keeps giving me errors: unable to create drive A:\, B:\, etc. What have I done wrong? Most likely, your credentials are insufficient for doing remote deploy. Remote Deploy tries to create a share on the local machine (the one hosting the web application), and if it cannot, you will see the error, which generally speaking, is a permission error. If the remote machine has filesharing disabled, you will encounter this error as well, so check this. Make sure that the credentials you have supplied are sufficient to log onto and create the c:\ansa\agent folder on the remote machine. Can you access the machine? - Go to a browser and type in \\machinename\c$ - if not, remote deploy cannot function correctly. Can you create folders on the remote machine? Have you typed in the credentials correctly? (Make sure you enter domain\administrator as the username in the remote deploy dialog). Other problems could be that the web application cannot find the files to copy; for example, the files are not where you state they are on the form.

I am still having problems deploying remote agents. First you need to ask two questions: 1) Can the remote machine be accessed from the machine hosting the web application? To do this, open a browser type in \\machinename\c$ 2) Can folders or files be created on the remote machines c$ from the machine hosting the web application? If you can do both of the above and you are still getting errors on the web application then it is more than likely a permission issue or a form issue (as described above). First, verify that the web application is running as the same user you were logged in as when you tried the two steps above. Also, make sure that you type the username and password correctly in the Remote Deploy form. When using a domain admin credentials you must enter domain\administrator as the username in the remote deploy form. For workgroup administration, you can enter the administrator user name and password to gain local admin rights to the machine you are deploying the agent to. If remote deploy returns with a message stating it cannot establish the network connection to the remote machine, it is quite possible that the user credentials are invalid. Check spelling on domain\user name as well as the password entered - the password should grant local admin rights to the local machine. 8

Other problem could be that the system could not find the file specified Verify that the folder specified for deployment is on the target machine (by default c:\ansa\agent) does NOT exist. Remote Deploy Issues: My sessions are timing out. There are a few possible solutions: Edit the following file in the C:\inetpub\wwwroot\ansaui\xml folder: webdb.config Change the settings to the following:

<ApplicationSettings> <ReceiveTimeOut Default="30000" Value="30000" /> <SendTimeOut Default="30000" Value="30000" />

Increase the Default Values to 90000 Increase the Connection Time out on the DEFAULT website properties

Increase Session Time Out and ASP Script Timeout for the AnsaUI website properties (Properties | Directory Tab | Configuration button | Options Tab)

Troubleshooting I am having trouble installing the evaluation version. I get a SQL access error or Login Failed error. What do I do? Check the following: make sure that the connection string in the following two places is identical: c:\inetpub\wwwroot\ansaui\xml\webdb.config, c:\ansa\controller\config.xml (for the controller). Additionally, make sure that the password for the database ANSA in SQL Enterprise Manager is the same as the password set in both the above files. NOTE: The default username is admin and the password is ansa. These are pre-configured in the webdb.config and controller config.xml files already. During the install, that user (with the password) is created when your ANSA database is installed. Make sure that in Enterprise Manager, security properties for the local SQL Server Group are set to SQL Server and Windows authentication. Weve also seen (very rarely) issues where, in a Windows 2003 Server environment, when the 2003 Server OS is Enterprise Version, that there appear to be IIS lockdowns where our installed web service does not work (access errors). Modifying the access security to the machine, particularly the web service installed, will rectify this issue. In addition, reinstalling the OS (to non-enterprise) will fix the problem as well.

I installed the web interface onto a fresh Windows 2003 Server machine. I am getting a page not found when I try to go to website http://localhost/ansaconsole. Why? 10

You probably do not have ASP.NET installed on the machine. Go to Control Panel, Add/Remove programs, Add/Remove Windows Components, and then double click on Application Server in Windows Components. Make sure ASP.NET and Internet Information Services are checked; if not, check either/both and click OK. You may be asked to provide the Windows 2003 Server install disk, which will in turn install ASP.NET and/or IIS; you should be able to access the local site. If this does not work, check the following: under the local web server properties, click on the Web Service Extensions. To check this, you need to get into Administrative Tools, IIS Manager, click on the local computer, and double click into Web Service Extensions. Make sure that the following are Allowed Active Server and ASP.NET v2.0.50727. Stop and restart the web service if you end up making the change to allow either or both of the above.

I installed the web interface onto a fresh Windows 2000 Server machine (same as above except for OS). I am getting a page not found when I try to go to website http://localhost/ansaconsole. Why? ASP.NET may not be installed correctly. Make sure the Microsoft .Net 2.0 has been installed. Also, enter the following at the Windows command prompt: Navigate to: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 and enter: aspnet_regiis i You will see: Start installing ASP.NET (2.0.50727). Finished installing ASP.NET (2.0.50727). Then, enter: regsvr32 aspnet_isapi.dll Refresh your browser page and it should come up properly.

I install an agent but it does not appear on the console. Typically, this is due to the IP address being incorrectly listed in the c:\ansa\agent\config.xml file. Review the install directions for the file and make sure that the IP address for the controller is accurate (as well as the port setting, which is typically 9311; however, it is configurable as long as you keep it consistent between agent and controller). There have been occasions, where, even though all port settings and IP address for the controller were accurate, that the agent still was unable to register with the controller. In this case (which is quite rare), set the local address settings in the agent configuration file to the actual IP address for the agent, then install and start the agent. This may fix the problem. Make sure the agent is actually running (it will show up in task manager on the agent machine as ansa.exe). Firewalls if the personal firewall is up, the ANSA agent will be unable to communicate with the controller. Verify this setting by going to Control Panel, Network Connections, Local Area Connection, Properties, and click on the Advanced Tab. Take the setting Internet Connection Firewall setting off in the cases where the agent machine is not reporting to the controller. If Service Pack 2 for XP is installed on an agent machine, the ports you are using for agent/controller communication need to be opened up (typically 9311 and 9312). Other 11

firewalls (Symantec, etc) can also impede communication between the agent and controller, so this needs to be checked as well in extreme cases. I install the controller but it does not show up on the console (under servers). Confirm that the ansad.exe process is running (in services and task manager). You can also check by navigating to the c:\ansa\controller directory with a command prompt and typing ansad q. This will indicate whether the controller service is running. If the controller is not running, stop and uninstall the controller service by going to c:\ansa\controller in the command prompt and type controller -s u Ignore any messages. Then type 'controller -c config.xml -i -r' This will install and start the controller.

I am trying to re-implement my SQL script I get an error that the database cannot be dropped. Make sure that the pull down menu for the database that is currently open (at the top of the screen near the middle, in Query Analyzer) is NOT set to ANSA.

I keep getting timeout errors in my ANSA Network Scan. How do I fix? Go to IIS Service Manager (in administrative tools on the machine where the ANSA web service is installed). Click down into the default web site; right click to get to properties. Set the connection timeout to a higher value than it currently is. Then, click on the tab home directory, and within Application Settings, click on Configuration. Click tab Options, and set both Session Timeout, and ASP script timeout to higher values. As a last resort, scan a smaller range of begin/end ip addresses. ANSA Agent Pre-deployment info for Windows XP with Firewall ON: Using Netsh command: Netsh firewall add allowedprogram program=c:\ansa\agent\agent.exe name=ansa mode=enable scope=all profile=all

12