It's great when great minds share information like this freely. It helps all of those searching for solutions to find the answers quickly. His web site is full of good stuff as well: http://www.unixwiz.net/
TechNet Virtual Labs - http://www.microsoft.com/technet/traincert/virtuallab/default.mspx allow you to test Microsoft's software in a 'sandbox' environment. I haven't tried one yet, but it seems to be a very good idea.
Best of all there's FREE!!!! You people know how I'm a big proponent of Free!
I keep getting prompted for credentials when I access it, I assume it needs admin rights on the exchange server.
I also had to re-create the client side scripts for .NET: C:\WINNT\Microsoft.NET\Framework\v1.1.4322> aspnet_regiis -c Start copying the ASP.NET client side script files for this version (1.1.4322.0). Finished copying the ASP.NET client side script files for this version (1.1.4322.0).
No matter what the EVM configuration files ( /etc/evmdaemon.conf and /etc/evmlogger.conf ) state, if you have the 'activity monitor' set up in evmdaemon.conf, any events that hit EVM will count against the threshold for the activity monitor. Even if you configure EVM to ignore or otherwise not log certain events, EVM will still trigger this activity monitor.
I had a ton of print jobs being printed certain hours of the day. I wanted to stop the LPD daemon from posting these events (stop it from being chatty), because they were just normal system functions/activity that I don't think should count against the activity monitor, escpecially since I know this server will be busy handling print jobs already. No matter what I tried, LPD always posted 3 events to EVM for each print job. It seems no matter what configuration changes you make, you can't tell LPD to shut the hell up. Even changing /etc/syslog_evm.conf didn't help at all. Surprise, surprise. Looks like the LPD daemon is hardcoded to post to EVM ----- which really sucks, you Compaq/DEC/HP engineers!!!:
LPD daemon started - Status: 0 PID: 1081011 LPD job submit requested - Status 0 Printer myprintername LPD job submit completed - Status 0 Printer mypritnername Job number 0
When enough of these events happened I would receive the following email message from EVM:
SUBJECT: EVM ALERT : EVM daemon: High event activity - exceeds 500 in 10 minutes
This high priority event is posted by the Event Manager (EVM) daemon when it detects a high number of events occurring over several minutes.
Action: Use the event viewer or the evmget(1) command to review the event log for the source of the activity. If the log does not show high activity around the time at which this event was posted, it is likely that the events were low priority, and hence were not logged. You can monitor low-priority events by running the evmwatch(1) command with an appropriate filter, or by temporarily reconfiguring the EVM logger to log low-priority events.
Note: You can change the parameters which control the posting of this event by modifying the daemon configuration file, /etc/evmdaemon.conf.
Formatted Message: EVM daemon: High event activity - exceeds 500 in 10 minutes
Event Data Items: Event Name : sys.unix.evm.daemon.event_activity Priority : 600 PID : 1048856 PPID : 1048577 Event Id : 326425 Member Id : 2 Timestamp : 24-Nov-2005 15:08:06 Host IP address : 192.168.1.1 Cluster IP address: 192.168.1.3 Host Name : host.domain.com Cluster Name : cluster User Name : root Format : EVM daemon: High event activity - exceeds $count in $period minutes Reference : cat:evmexp.cat:100
Variable Items: count (INT32) = 500 period (INT32) = 10
Migration of a single Windows 2000 print server to a Windows 2000 clustered print server.
'printserver1' is the name of the old print server.
I ran the Print Migrator wizard to get the printers on the cluster. My plan: on the night of the conversion, I would shutdown printserver1 and add a "network name" resource in the cluster configuration for printserver1 so that any clients that didn't run the vbs logon script(see my migration blog article) to change the connections would still be able to print without any noticeable effects. That was my plan at least. The following was the Murphy's law version of what happened:
After the shutdown of printserver1, tried to bring online the printserver1 'network name' resource. But, I couldn't bring the printserver1 'network name' resource online. I kept saying 'failed'. The following events were posted to the system eventlog.
NOTE: make sure the advanced property, 'affect the group', is turned off, otherwise if you do have problems with the resource coming online, it won't cause the group to fail. You can always turn that option on once the resource is stable and working.
Event Type: Error Event Source: ClusSvc Event Category: (2053) Event ID: 1052 Date: 11/23/2005 Time: 2:00:24 AM User: N/A Computer: NODE1 Description: Cluster Network Name resource 'printserver1' cannot be brought online because the name could not be added to the system. Data: 0000: 0e 50 00 80 .P.
Windows 2000 cluster, running IIS ftp as a cluster resource: Event log entry almost every 5 seconds, even when no connections are being made to the IIS ftp server:
Event Type: Error Event Source: MSFTPSVC Event Category: None Event ID: 8 Date: 11/22/2005 Time: 5:55:45 PM User: N/A Computer: NODE1 Description: FTP Server could not create a client worker thread for user at host 192.168.1.50. The connection to this user is terminated. The data is the error. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.
Solution: Put the IP of the cluster (192.168.1.50 in this case) in address restrictions and the event log entry no longer happens, except for when an unauthorized IP tries to connect to the cluster ftp. You must restart the IIS resource in the cluster to stop the event log from appearing.
C:\>ftp cluster Connected to cluster.domain.com. 530 Connection refused, unknown IP address. User (cluster.domain.com:(none)):
C:\>ftp node1 Connected to node1.domain.com. Connection closed by remote host.
The upgrade from EPS version Fall 2004 to Spring 2005 IU2 caused the EPS service name to change from "epicprintservice" to "EpicPrintService722". Had to change that in the cluster configuration which requires the resource to be taken offline/ brought online when change is complete.
Caveats to running EPS on a windows print cluster:
1. One locally installed printer must exist on each cluster node/member. Restart(take offline/bring online in cluadmin) the EPS service if the printer was installed while EPS was running.
2. Printer Path in the Epic device table needs to be the full unc for the printer. Using the short name (the printer name by itself) doesn't work if all your printers are defined on the cluster name and not on the nodes directly (which is the way print clustering works).