| Author |
Message |
|
|
Hi John,
the CoreConfigurator for Server Core will help you set the common settings and enable remote management of Server Core.
http://blogs.microsoft.co.il/blogs/guyt/archive/2008/03/22/windows-server-core-coreconfigurator-to-the-rescue.aspx
You should then be able to manage the server through MMC snap ins remotely.
http://www.petri.co.il/remotely-managing-windows-2008-server-core-firewall.htm
Hope this helps you with the troubleshooting.
|
|
|
Could you give us some more information to help troubleshoot...
Are you trying to get email integration working or Calendar Sync?
Version of exchange.
Screenshot of your SysAid email integration settings.
I can also generate that message by going to Preferences - Integration - Calendar Sync Settings - Test the exchange settings. I haven't setup Calendar Sync so this is to be expected.
If you are trying to simply get email integration working, this is the wrong tab. That is done on the email tab, 'Create a new account'.
|
|
|
The behaviour you have described is fairly typical of database files. When you delete contents of the database file, the db file itself remains the same size.
In Microsoft databases the process is called a 'compact and repair'. This would essential flush out that blank space that the database file is currently storing and reduce its overall size. I didn't turn up any tools from a quick google that can perform this on a Derby database, but I am sure they exist.
How big is your database?
What is your concern with the size of the database.. i.e. Are you running out of disk space or do you feel its size could be the cause of a performance issue?
If you feel Derby is not for you, SysAid is able to run on an SQL back end, however I haven't seen any instructions on how to set this up. It might be a process that Ilient needs to be involved in to convert your database file.
|
|
|
Updates to .msi packages deployed via GPO come in a file format of .msp. These types of updates should directly update the installed package and are provided by the software vendor.
When a package does not have an .msp file to do updates with (such as the SysAid agent as far as I know), you may need to uninstall the old package before installing the new one if it can't be installed over the top of the old. This can also be done via group policy....
Question: When the 'new' installed agent checks in - will it use the same Asset in the SysAid database?? I'm not sure so test this out before updating your agents via this method... you may end up duplicating all your assets.
Again I haven't done this, but this should get you going..
Server 2008.
To Deploy an initial agent package:
Open Group policy management console - create (or edit) your deployment gpo
Computer Config - Software Settings - Software installation - Right Click - New - Package (choose the .msi file)
Choose 'Advanced' - OK
Deployment Tab: Select Uninstall this application when it falls out of scope of management (this is optional, it means the package will be removed if this GPO no longer applies to the AD object. eg. If you move the computer to a different OU outside the scope of this GPO)
Go to the Modifications tab to add your .mst file if you have create one
Assign the GPO to the OU containing the PC's that you want to deploy the package to
To Update (or cleanly install) a new agent package when one is already deployed:
Use the same process to create a new GPO with the same settings and then..
Upgrades Tab: Click Add - A specific GPO - Browse - Locate the GPO from above and click OK - At the bottom choose "Uninstall the existing package" or "Package can upgrad over..."
Go to the Modifications tab to add your .mst file if you have create one
Assign the GPO to the OU containing the PC's that you want to upgrade
|
|
|
Here is the documentation page, you should be able to find what you are looking for.
http://www.ilient.com/Sysforums/forums/documentation.page
|
|
|
Hi fgonzalez,
I think this is the correct way to 'assign' the package to the 'computers'. This way it will be install by one of the inbuilt accounts with administrative privelages (probably the System account). From what you have described, it sounds as though you have assigned the package to the users and therefore the installation runs at user login time in the context of that user.
http://support.microsoft.com/kb/816102
Again I haven't tried this, but I'm sure this will allow you to deploy the agent to the computers (remember the computers need the agent, not the users) without compromising security for the users.
|
|
|
I haven't deployed the agent via group policy and I'm glad you got it working.
However this looks more like a temporary work around to 'get it out there' as you have permanently made a sacrifice to each computers' security to simply deploy the agent.
There must be a better method that doesn't lower your security level.
|
|
|
Maybe this is what you are looking for:
http://www.ilient.com/Sysforums/posts/list/2683.page
Don't forget to vote!
|
|
|
This is exactly why the IP address should not be used when deploying the agent. Instead you should be deploying them using an FQDN, this scenario would then not be an issue.. simply update the A record or CNAME.
Since now you have to update the 'field' anyway, you might as well do it right with a DNS entry and get your internal/external DNS setup to accomodate.
For restarting the services...
Prior to losing connection to those servers, you could setup a simple schedule task or bat file, or call the bat file from a scheduled task.. you get the idea 
Anyway, you want the commands to be this:
net stop "SysAid Agent"
net start "SysAid Agent"
If you don't know exactly when the cutover will be, schedule them to run every couple of hours.. the first task, then the second task a minute after the first (to give enough time to stop, it only takes a few seconds).
And remember, DNS is your friend!
|
|
|
If you at your office, the best way to have the agents check in is via an external DNS name to your site - no VPN required.
However if you are at home and want to connect to the client, the way the SysAid agent works currently this is not going to work. Essentially in that situation you need some other method but then it gets messy i.e., creating VPNs and using RDP...
What we need is a firewall friendly solution such as this:
http://www.ilient.com/Sysforums/posts/list/2724.page#12359
|
|
|
We are in the same position as you Timmothy, we need to be able to access multiple client sites from multiple locations and we are finding this is not really working for us due this limitation in SysAid, and as such have begun looking for alternatives to provide the firewall friendly remote support we need. There are a number of other systems out there than can provide this. I do like the integration of all the systems in the one product (SysAid), but, if we have to break it out and change to a RC tool and a Ticketing tool, we will.
I'm not trying to make threats or anything, its just that the reality is; this functionality is a requirement to provide remote support because of a) remote workers, b) firewall security for both ends of the connection and c) it is not always possible/ nor is it practicle to have to update and maintain static IP's and port forwarding rules constantly.
I would prefer not to have to change our ticketing system and re-deploy agents so I'm hoping there is some attention to this on the next release. Maybe if we can get some more votes on the feature request (scroll up a bit), it will be looked at and prioritised.
|
|
|
This is such an important and needed feature, it solves the two issues of having to statically assign and open ports on your firewall, which we know is both inconvenient and a potential security issue.
There is a feature request here, which I think we should all get behind so it gets put on the developers radar:
http://www.ilient.com/Sysforums/posts/list/2724.page#18186
A second major benefit is that it allows us to begin offering support from anywhere, even if we are at a hotel, at home (after hours) or any where other than in our office (as was previously mentioned)
Timmothy, this feature is probably nothing you will be able to implement by modifying your installation files.
Following up the previous requests, has there been any update to the roadmap for this?
|
|
|
|
Does the technician account need to install software on servers or just workstations?
|
|
|
Not sure if this is a known issue, but here is my experience...
I have dual monitors on my desktop, and when controlling a client machine with dual monitors, I cannot see their second monitor if I expand their desktop view accross my monitors (see attached image). The only way to view the clients two screens is to view their first screen on one of my monitors and use the scroll bar at the bottom to view their second monitor.
My workstation is Server 2008, 64bit
SysAid Server v 6.5.08
Client PC - XP x86
SysAid Agent 6.5.07
Mirror Driver installed v 1.0.0.19
Remote PC is being controlled accross the internet.
Has anyone else come accross this and is there a fix?
|
|
|
Prior to using email integration users where emailing you directly?
Without email integration you must have been entering the service requests manually to SysAid.
If I understand the problem correctly you would like have the email integration create the service request for you automatically however you would like to receive a notification of the new service request as if it appears from the original sender.
I don't think this is possible through SysAid at this stage however you could set something up to give you a similar effect.
This may work:
1) Assume the users send their support email requests to "support@yourcompany.com"
2) If you are using exchange, also forward a second copy of this email to a distribution group "technicians@yourcompany.com" and add to this group the users who should be notified of new requests.
3) Configure your SysAid notifications for new service requests
You should now get a copy of the original email and so will the SysAid server, you will also get a second email with the related SR number.
|
|
|
