7021931: Automating SSH, SFTP, and SCP with Windows Scheduled Tasks

Automating SSH, SFTP, and SCP connections using the Windows Scheduled Tasks utility and the command line requires the following steps:

Note: If the Windows account that is used to run the task is a member of the Administrative group, skip both Step 3 and Step 4. There is no need to add privileges to the Administrative account. However, if your company security policy prohibits running a task with an account that is part of the Administrator’s group, follow Step 3 and Step 4 to amend the account permissions.

Step 1: Configure Public Key Authentication with a Blank Passphrase

  1. Launch the Reflection FTP client.
  2. Under “Connect to FTP Site,” click New.
  3. Enter the name of the host you will be connecting to. Click Next
  4. Under “Login Information,” click the Security button.
  5. Click the “Secure Shell” tab.
  6. If “Use Reflection Secure Shell” check box is not already checked, select it.
  7. Click Configure.
  8. On the User Keys tab, click Generate.
  9. Select the key type and length required to satisfy your corporate security policy. Select the No passphrase check box, and then click Create. Click Save. The new private key appears in the User Keys list.
  10. Verify that the new key is selected (a check mark is displayed in the Use column).
  11. Click Upload, and follow the prompts to upload the public key to the remote host. You will most likely be prompted for a password during this process.
  12. Once the upload process has completed, click OK.
  13. Click OK to close the “Security Properties” dialog box.
  14. In the Login Information dialog box, click Next.
  15. In the User name field, enter the user name that should be used for the automated transfers. Click Next.
  16. Click Finish. By default, we will try to connect to the remote SFTP server using the new key we have generated from above.

If connection is successful, key authentication is now configured for all SSH, SFTP, and SCP connections from the Windows account you are logged in with, to the specified host, using the specified host account. This includes both Windows-based clients and command line clients.

If a banner requiring user interaction is normally displayed when you connect to the host, on the General tab, change the Logging Level to Quiet. This step is not necessary if you do not have a login banner, or if you are using the command line client, as no user interaction is required in those scenarios.

Note: If public key upload was successful but public key authentication fails, it is possible that the remote SFTP server stores the user’s keys in a none default location. Please contact the remote administrator and have the key relocated to the correct folder.

Step 2: Create a Batch File with Connection Commands

Create a Windows batch (.bat) file that contains the connection commands appropriate for your task. For a complete list of SFTP, SCP, and SSH, syntax and commands, open a Windows command prompt and enter <command> -? , where command is SFTP, SCP, or SSH.

Batch file examples:

"C:Program FilesAttachmateRSecuresftp.exe" -B "C:pathbatch_file.txt" user@host

"C:Program FilesAttachmateRSecurescp.exe" user@host:file "C:pathfile"

cmd /c ""C:Program FilesAttachmateRSecuressh.exe" user@host ls > "C:pathfile.txt""

Before proceeding, run each batch file manually to ensure it works correctly.

If the batch file is not working, you can collect error and debug logging information for troubleshooting using syntax such as:

"C:Program FilesAttachmateRSecuresftp.exe" -vvv -B "C:pathbatch_file.txt" user@host 1> "C:pathdebug.txt" 2> "C:patherrors.txt"

Note the following:

  • If you prefer not to create a batch file for the required tasks, you can configure the task to run the appropriate product executable instead (sftp.exe, scp.exe, or ssh.exe). In this case, after creating the task in “Step 5: Configure Windows Schedules Tasks to Run the Batch Files,” edit the task to include the appropriate command syntax, as shown in the examples in Step 2. (This customization is done in the Run field of the Task tab.)
  • If you need to run the batch file or executable with a Windows account other than the one configured for public key authentication, you can use the –k switch to point to the .ssh directory of the configured account, which contains the required keys and configuration file (named config).

Step 3: Assign “Log on as a Batch Job” Permissions

For tasks to be run by the Task Scheduler, Windows requires that the account running the task be logged on to Windows or have “Log on as a batch job” permissions. These permissions are automatically assigned:

  • To members of the Administrator’s group.
  • In Windows XP, if you are a member of the Users group and you create a scheduled task.

Note: When a task is created, these permissions are not automatically added for members of the User’s group in Windows 7 or Windows Server 2008.

If the account you plan to use does not have “Log on as a batch job” permissions, follow the steps below to add these permissions to the account.

Warning: For security reasons, we recommend that you only grant these additional privileges to the required user or users.

  1. Login to the Windows system with an account that is part of the Administrator’s group.
  2. Click Start > Run; in the Open field, enter secpol.msc, and then click OK.
  3. Double-click Local Policies > User Rights Assignment.
  4. Double-click Log on as a batch job.
  1. Click Add User or Group, and add the user or group.
  2. Click OK to save the change and exit the properties window.

Step 4: Assign Account Permissions to the Reflection SSH Com Server

If a scheduled task is configured to run sftp.exe, scp.exe, or ssh.exe, and both of the following are true, the task will fail due to insufficient privileges:

  • The user account used to generate the public keys and to schedule the task does not belong to the Administrator’s group, and
  • The user is currently logged out of Windows.

When this occurs, the Last Results column (Last Run Results in Windows 7 and Windows Server 2008) in Scheduled Tasks displays 0x57. This code indicates that additional privileges are required to run the Reflection SSH COM server (rssh.exe) when the user is not logged in to Windows.

The privileges required to run the executable are Local Launch and Local Activation. These permissions are automatically assigned to members of the Administrator’s group. If the public key was generated by, and the scheduled task belongs to, a user who is part of the Administrative group, you can skip this section. Otherwise, follow the steps below to add these specific permissions to the user account used to generate the key and run the scheduled task.

Warning: For security reasons, we recommend that you only grant these additional privileges to the required user or users.

  1. Login to the Windows system with an account that is part of the Administrator’s group.
  2. Click Start > Run, in the Open field, enter dcomcnfg.exe, and then click OK.
  3. Double-click Component Services > Computers > My Computer and click DCOM Config.
  4. Scroll down to the object named {AA76F3C3-B544-4E32-B5CC-38F0B09CB5F}, right-click the object and click Properties. You are now in the properties of the SSH COM object.
View Full Size

Figure 1 - Access the Properties of the SSH COM Object
Figure 1 – Access the Properties of the SSH COM Object
  1. On the Security tab, in the Launch and Activation Permissions group, select Customize, and then click Edit.
  2. Click Add. Locate and add the required user(s) or group(s), and then click OK.
  3. In the “Group or user names field,” select the user or group
  4. In the Allow column, select the Local Activation check box, and verify that Local Launch is already selected. (Local Launch should be selected by default.)
Figure 2 - Configure new user (Lilly) for Local Launch and Local Activation Permissions

Figure 2 – Configure new user (Lilly) for Local Launch and Local Activation Permissions

  1. If you are configuring multiple users or groups, repeat steps 6 through 8 for all users and groups.
  2. Click OK > OK and close the Component Services dialog box.

Step 5: Configure Windows Scheduled Tasks to Run the Batch Files

Follow these steps to automate the file transfer using Scheduled Tasks.

In Windows 7 or Windows Server 2008:

  1. From the Administrative Tools menu, select Task Scheduler.
  2. Click Action > Create Basic Task.
  3. When prompted, enter a name for the task, then click Next.
  4. Under Task Trigger, select “When do you want the task to start.” Click Next and fill in the details.
  5. Under Action, select “Start a program,” click Next, and then browse to and select the batch file you created in Step 2: Create a Batch File with Connection Commands. Click Open, and then click Next.
  6. Under Finish, select “Open the Properties dialog for this task when I click Finish.”
  7. On the General tab of the Properties dialog box, under Security options verify that the user name shown under “When running the task, use the following user account” is the Windows account used to setup the public key authentication. If not, modify this setting.
  8. Select “Run whether user is logged on or not,” and then click OK.

Note: If the Windows account that is used to run the task is a member of the Administrative group, under the General tab, select the option “Run with highest privileges.”

In Windows XP:

  1. From the Control Panel, select Scheduled Tasks.
  2. In the Scheduled Task Wizard, browse to and select the batch file you created in “Step 2: Create a Batch File with Connection Commands,” and then click Open.
  3. When prompted, enter a name for the task, then set the frequency, start time and start date.
  4. Configure the task to run under the Windows account used to setup the public key authentication.
  5. Select “Open advanced properties for this task when I click Finish,” and then click Finish.
  6. Make sure that “Run only if logged on” is not selected (the default) and click OK.

At this point you should see your new task listed in the Task Scheduler (or Scheduled Tasks) window.

Test the New Task

While still logged in to Windows, right-click the new task and select Run. If the task successfully runs, the Last Result field in the Scheduled Tasks window should show 0x0. (On Windows 7 and Windows Server 2008, this “Last Run Result” field also includes the statement “The operation completed successfully.”) If you encounter problems, please refer to the following:

  • In Windows 7 and Windows Server 2008, in the Task Scheduler window, select the task, click the History tab, and see if there are any logged errors.
  • In Windows XP, in the Scheduled Tasks window, click Advanced > View Log, and see if there are any logged errors.

Additional Troubleshooting help.

Set the Final Schedule

Once you have verified that the task can be successfully run, make any additional configuration tweaks to the task schedule, and you are done. The automated SSH, SFTP, or SCP task should now run automatically.

Related:

7021355: Obtaining Host Integrator Traces and Configuration Files for Technical Support

Model Files

These files are typically located in <Documents>AttachmateVerastreamHostIntegratormodels (beginning in version 7.1) or <VHI installation directory>models<model name> (in version 7.0 and earlier). This includes files with .model and .snapshot extensions. Additional subdirectories may contain trace, deployment, and event handler files, depending on the version of Verastream installed and the features enabled.

When sending model files to Technical Support, please zip the entire <model name> directory. The model deployment package is insufficient, as it does not include snapshots or event handler source.

Model Debug Messages (.vmr)

Beginning in version 6.0 Session Server and Design Tool can generate model debug messages files with .vmr extension.

By default, the server .vmr files are created in subdirectories under <VHI installation directory>/etc/reports.

For information on model debug messages, see Technical Note 10065.

Server Configuration Details (sesssrvr.config)

Obtain the server configuration file, <VHI installation directory>/etc/sesssrvr.config, which contains the current Verastream server configuration information.

In version 7.5 SP1 or higher, if a sesssrvr.config.invalid file also exists, please provide it to Attachmate Technical Support for troubleshooting.

Design Tool Event Log (.applog)

Follow the steps below to capture a Design Tool Event Log (.applog).

  1. Load the Verastream model in Design Tool.
  2. Click Debug > Event Log > Logging Options.
  3. In the Log the following drop-down box, select Log All Messages, and then click OK.

By default, this log file is stored in the <VHI>etclogsdestool directory.

Setup Logs

When installing version 7.0 or higher on Windows, temporary configuration files and installation logs are written to the folder specified by the %TMP% environment variable (such as C:Documents and Settings<user name>Local SettingsTemp on Windows XP). If the installer reports a failure, refer to the appropriate log file(s):

Setup Debug Output

If you have an issue related to installation of version 6.6 or earlier on Windows, you may need to run setup debug (at the Command Prompt) and note all the debug popup windows that appear, particularly the last message before the install problem occurs.

If you have a product installation issue on UNIX/Linux, error detail is displayed in the process output (terminal session window).

Patch or Service Pack Installation Log Files

If you have an issue related to the installation of a VHI service pack or hotfix for version 6.6 or earlier, the log file from this installation may be useful to help diagnose the issue. It is typically created in the same directory where the rtpatch executable was run. (For example, after installing VHI version 5.5 Service Pack 1 on Sun Solaris, the file, solaris55_p611.log, is created in the same directory where rtpatch was run.)

Windows Minidump (*.dmp)

In the event of an unexpected exception in Design Tool or Session Server on Windows, minidump files are generated to assist Attachmate with debugging the issue. Please provide the *.dmp files to Technical Support, which may be located in one of the following directory folders, depending on your environment:

  • Session Server: The VHI installation directory as indicated by VHI_ROOT environment variable, typically C:Program Files (x86)AttachmateVerastreamHostIntegrator (version 7.0 or higher)
  • Design Tool: Specified by TMP environment variable, or <Documents>AttachmateVerastreamHostIntegrator (version 7.1), where <Documents> is typically C:Users<user name>Documents (on Windows 7) or C:Documents and Settings<user name>My Documents (on Windows XP)

If *.dmp files are not found in the above locations, the following registry key may be modified to explicitly set a different location to generate minidumps:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps

For more information on the values set within this registry key, see http://msdn.microsoft.com/en-us/library/bb787181(v=vs.85).aspx.

Dr. Watson Log (drwtsn32.log)

In the rare event that you receive the following Microsoft Windows Dr. Watson error, please provide Technical Support with the system Drwtsn32.log file.

"Verastream Host Integrator Session Server has encountered a problem and needs to close. We are sorry for the inconvenience."

The Drwtsn32.log text file is automatically generated by Microsoft Windows. By default, this file is located in C:Documents and SettingsAll UsersDocumentsDrWatson.

Java Error Report (hs_err_pid*.log)

If you see one or more of the following symptoms, your model event handler Java code may be causing the Script Manager JVM to unexpectedly exit:

  • Design Tool displays “An error occurred while communicating with the script manager: Socket error – Socket not connected.”
  • Session Server unexpectedly restarts.
  • Logged error message ID 4306: The script manager is offline.

Look in your <VHI>/lib/java directory for text files named hs_err_pid<nnnn>.log, where <nnnn> represents process ID numbers.

Event Handler Console or Traps Output (traps.out)

For information on event handler debugging output, see the product documentation.

Operating System Log

For service startup events, information may be found in the operating system log:

Windows: Control Panel > Administrative Tools > Event Viewer > Application Log

Sun Solaris:/var/adm/messages

Red Hat Linux:/var/log/messages

IBM AIX: log location configured in /etc/syslog.conf (e.g., *.debug or daemon.error line)

Startup Debug Logs (atstart.*.out)

For information on generating atstart debug output for service startup issues, see Technical Note 10078.

Traces

For more information on various traces that can be used for troubleshooting, see Technical Note 10102.

Uploading Files to Technical Support

After obtaining the trace and configuration files requested by Technical Support, go to http://upload.attachmate.com/ to send the files, or attach it to your Service Request as described in Technical Note 2327.

Related:

7022016: Using Debug Mode to Troubleshoot Reflection for Secure IT Windows Server

Running in Debug Mode—Best Practices

The following tips will help you create a debug log with information you can use to troubleshoot issues.

  • You must have administrative privileges to turn on debug mode on the server side.
  • To get the best results, run both the server and client in debug mode simultaneously. This way you can compare the debug output for both of them and better pinpoint your problem. This is especially helpful when troubleshooting authentication issues.

Attachmate technical support may require a debug log in order to troubleshoot your problem.

Starting Debug Mode

Use the method appropriate for the application you are running:

Reflection SSH Windows Server Version 7.x or Higher

For both SSH and SFTP, debug information can be collected in a text file, the Windows Event Viewer, or both. The data captured in each location is configured independently, allowing different logging levels to be used simultaneously.

Enable Logging to a Text File

Logging to a text file is disabled by default. To make changes:

  1. Windows Server 2012: Go to Apps > Attachmate Reflection > Reflection SSH Server Configuration.

Windows Server 2008: Click Start > All Programs > Attachmate Reflection > Reflection SSH Server Configuration.

Windows Server 2003: Click Start > Programs > Attachmate Reflection > Reflection SSH Server Configuration.

  1. Click the Configuration tab in the Reflection for Secure IT Server window.
  2. In the left pane, click Debug Logging.
  3. Check option “Enable debug logging to log file”.
  4. Select the preferred options. Each category provides increasing detail. The default configuration of Errors, Warnings, and Information will record file transfer events or login events. For troubleshooting, Protocol details log level is recommended. For full control of which events are recorded, click the Custom button.
  5. Use the Log file information options to configure log file rollover by file size or by time.
  6. Click File > Save Settings to retain the new settings for new connections. Existing connections will not be affected.

Logging to the Windows Event Viewer

Logging to the Windows Event Viewer is enabled by default to log events, errors and warnings. To make changes:

  1. Windows Server 2012: Go to Apps > Attachmate Reflection > Reflection SSH Server Configuration.

Windows Server 2008: Click Start > All Programs > Attachmate Reflection > Reflection SSH Server Configuration.

Windows Server 2003: Click Start > Programs > Attachmate Reflection > Reflection SSH Server Configuration.

  1. Click the Configuration tab in the Reflection for Secure IT Server window.
  2. In the left pane, click Event Logging.
  3. Select the preferred options. Each category provides increasing detail. For example, selecting Errors and Warnings will not record file transfer events or login events to the Windows Event Viewer. For troubleshooting, Protocol details level is recommended. For full control of which events are recorded, click the Custom button.
  4. Click File > Save Settings to retain the new settings for new connections. Existing connections will not be affected.

Running Debug from the Command Line

To run debug from the command line, follow these steps:

  1. At the server console, or as a remote administrator, log in to the server.
  2. Change to the “<Drive>:Program FilesAttachmateRSecureServer” directory.
  3. Stop the server:
rsshd -stop
  1. Start the debug receiver and the ssh service:
rsshd –start –d4

-d4 (level 4) is equivalent to enable Protocol details log level in Debug Logging pane.

Debug data will be saved to the following folder, depending on your server:

Windows Server 2012: <Drive>:ProgramDataAttachmateRSecureServerLogs

Windows Server 2008: <Drive>:ProgramDataAttachmateRSecureServerLogs

Windows Server 2003: <Drive>:Documents and SettingsAll UsersApplication DataAttachmateRSecureServerLogs
  1. Connect to the server using an ssh client to capture debug output to the terminal window or debug log file.
  2. Stop the server:
rsshd -stop
  1. Restart the server:
rsshd –start

More information regarding debug logging can be found in online help under Troubleshooting.

Reflection SSH Windows Server Version 6.1

The Application Event Viewer utility logs events on the Reflection SSH Windows Server. Follow the steps below to use and configure the Application Event Viewer.

If the event viewer does not provide the information you need to troubleshoot a problem, try Running Debug from the Command Line, described below.

Using the Application Event Viewer

To use the event viewer, follow these steps:

  1. Click Start > Programs > WRQ Reflection > SSH Server Configuration.
  2. In the right pane of the Server settings screen, click the View Event Log button.
  3. In the left pane under Event Viewer, click Application. In the right pane, click the Source column heading to sort by source.
  4. Scroll to the WRQ Reflection for Secure IT Server or WRQ Reflection for Secure IT SFTP Server entries. There will be Information, Warning, and Error messages.
  5. Double-click an entry to open the Event Properties dialog box and view specific information about the event.

Configuring the Application Event Viewer

You can configure which events are logged in the Reflection SSH Windows Server Configuration dialog box.

  1. Click Start > Programs > WRQ Reflection > SSH Server Configuration.
  2. In the left pane under Server Settings, click General.
  3. In the right pane in the Event log filter section, select the check boxes for the events you want logged: Errors, Warnings, and Information. By default, just errors and warnings are selected.
Selecting only Errors logs Errors, Warnings, and Information events.

Selecting only Warnings logs Warnings, and Information events.

Selecting only Information logs Information events.
  1. Click OK.

Running Debug from the Command Line

To run debug from the command line, follow these steps:

  1. At the server console, or as a remote administrator, log in to the server.
  2. Change to the “<Drive>:Program FilesF-Securessh server” directory.
  3. Stop the server:
fsshd2 -stop
  1. Start the debug receiver and the ssh service:
fsshd2 -d6

You can run debug at several levels. Level 1 (example: fsshd2 –d1) gives you very simple debug output, while level 9 provides very detailed debug output. Typically, level 6 is sufficient for troubleshooting most issues.

Note: The –p <port> option can be used to start the server in debug mode on a non-default port.

Output will be logged to the terminal window. To write the debug information to a file, issue the following command:

fsshd2 –d6 >debug-log.txt 2>&1

Output debug-log.txt is saved to the “<Drive>:Program FilesF-Securessh server” folder if no specific path is given.

  1. Connect to the server using an ssh client to capture debug output to the terminal window or debug log file.
  2. Use the keystroke Ctrl+c to exit debug.
  3. Restart the server:
fsshd2 -start

SFTP Server Version 6.1

You can view SFTP server events in the Application Event Viewer. Follow these steps to configure which sftp events are logged in the Reflection SSH Server Configuration dialog box.

  1. Click Start > Programs > WRQ Reflection > SSH Server Configuration.
  2. In the left pane under Server Settings, click SFTP Server.
  3. In the right pane in the Event log categories section, select the check boxes for the events you want logged: User login/logout, Uploads, Downloads, Directory listings, or Modifications. Both scp and sftp file transfers are logged.
  4. Click OK.

Related:

7022013: Migration and Upgrade to Reflection for Secure IT Windows Server 7.1 or Higher

Upgrading to Reflection for Secure IT version 7.1 or Higher from 7.0

If you are upgrading an existing installation of Reflection for Secure IT version 7.0, note the following:

  • If the server is running when you apply the upgrade, the installer stops the service and any existing client connections are disconnected.
  • We recommend that you back up your server configuration file before upgrading. The backup will be useful if you want to revert to an earlier version at some point in the future. The configuration file is located in the following folder:

Windows Server 2008: C:ProgramDataAttachmateRSecureServer

Windows Server 2003: C:Documents and SettingsAll UsersApplication DataAttachmateRSecureServer

  • After applying the upgrade, you need to restart Windows to complete the installation.

Automatic Migration of Reflection for Secure IT 6.x and F-Secure Settings

When you install Reflection for Secure IT Windows Server 7.1 or higher on systems with Reflection for Secure IT version 6.x or an F-Secure server, Reflection for Secure IT automatically migrates your current identity (host key and certificates) and settings.

Note: You can have both products (a 6.x version and a 7.x or higher version) installed on the same system at the same time, and both can be running if each product listens on a unique port. See Migration Example for Testing below.

The migration occurs the first time you:

  • Start the Attachmate Reflection for Secure IT Server service. When you restart Windows, the service starts automatically. (Restarting Windows is required to complete 7.x or higher installation.) This triggers the migration and starts the server using the migrated key and settings. (You can also start the service manually using the rsshd command line or using the Windows Computer Management console.)

-or-

  • Start the server console. This triggers the migration of keys and settings without automatically starting the server.

Note: The service cannot start if an earlier version server is still running using the same port.

Key Location

Existing host keys (hostkey and hostkey.pub by default) are copied to the new key location, so you don’t need to make any changes to clients that are configured to trust your current host key.

Windows Server 2008: ProgramDataAttachmateRSecureServer

Windows Server 2003: Documents and SettingsAll usersApplication DataAttachmateRSecureServer

Configuration File in Version 7.1 or higher

Settings in your earlier version’s sshd2_config file are migrated to the new XML configuration file, named rsshd_config.

Windows Server 2008: ProgramDataAttachmateRSecureServerrsshd_config.xml

Windows Server 2003: Documents and SettingsAll usersApplication DataAttachmateRSecureServerrsshd_config.xml

For a summary of which settings are supported and how settings are migrated to the newer XML format, see the “Table of Migrated Settings” topic in the Reflection for Secure IT User Guide, available from http://support.attachmate.com/manuals/rsit_win_server.html.

For information about how to read the XML server settings file, see Technical Note 2289.

Migration Log File

Migration information is saved to the migration log file when the Reflection for Secure IT version 7.x console is started or when restarting Windows after installation.

Windows Server 2008: ProgramDataAttachmateRSecureServerLogsmigration.log

Windows Server 2003: Documents and SettingsAll usersApplication DataAttachmateRSecureServerLogsmigration.log

Password Cache File

If you used a password cache in 6.x, cached passwords are migrated from rsitdapc to the following files:

In 7.1: RSIT_Cache (contains cached passwords) and RSIT_Cache.bin (contains the key to encrypt and decrypt entries in the password cache.)

In 7.2 or higher: RSITDatabase (contains cached credentials in the database encrypted using AES 256) and RSITDatabase.sec (contains the key required to decrypt the credential cache.)

These files are moved to the following locations:

Windows Server 2008: ProgramDataAttachmateRSecureServer

Windows Server 2003: Documents and SettingsAll usersApplication DataAttachmateRSecureServer

Notes about Automatic Migration

  • Automatic migration will not take place if you have already uninstalled your prior version.
  • If you have an existing XML settings file, the server will not migrate the settings from a previous version’s settings file. This enables you to configure a single settings file and install it onto multiple servers.
  • You can manually migrate settings using the rsshd command line utility with the -m option.

Migration Example for Testing

While testing, you can leave your older 6.x product installed and listening on default port 22. When you install the new 7.x or higher product, use port 2222. After testing is complete, shut down the old product and change the port in Reflection for Secure IT version 7.1 or higher to 22. Migration of settings occurs one time, during installation.

Note: Any changes that you make to the old product while testing or running both products at the same time will not be carried forward to the new product.

Related:

Adding event source to Standalone Wincollect from command line

I choose to use standalone wincollect in our environment becaue only this contain Centralized Credential option what i need to regularly change the domain user password who has right to read event logs remotely.
But now i need to add more than 100 log source from the wincollect console one by one with a same settings.
Is there any way to bulk add or add from some script or using a list or a command line parameter?
I see that it works when you install wincollect to add a log source immediatelly from commnad line, but how it works after i installed the wincollect agent successfully?

Related:

Clients not updating when Network Application Monitoring is Enabled

I need a solution

Hi, I was trying to enable network application monitoring so I can “Allow and Log” when an application change is deteced on client computers. But when I enable network application monitoring, I notice the policy doesn’t update on all of the clients computers (stays at the old policy serial number). When I disable network application monitoring, the policy starts updating again. I am running SEPM 12.1.7061.6600 on Windows Server 2016. Any help on this would be appreciated.

Thanks

0

Related:

Re: vProxy – FLR error when mounting

Hello Chris, From the configuration requirement side: From the VMware administration guide, could you please confirm the below settings are applied before attempting a FLR: Entering management credentials for the Data Domain resource (instant recovery and User mode file-level restore only) When performing an instant recovery of a virtual machine or file-level restore in User mode, ensure that you provide the management credentials for the Data Domain resource prior to initiating the recovery. Procedure 1. In the NMC Administration window, click Devices. The Devices window displays. 2. In the expanded left navigation pane, select Data Domain Systems. 3. In the right details pane, right click the Data Domain system and select Properties. In the Access pane, enter the management credentials. Management host, Management user, and Management password. The Management user should have Data Domain administrator privileges. a. In the Management host field, specify the host name of the Data Domain system used for management commands. b. In the Management user field, specify the username for a Data Domain user that has admin access. For example, sysadmin. c. In the Management password field, specify the password of the management user. d. In the Management port field, specify the management port. By default, the port is 3009. If required, in the Configuration pane, update the export path. EMC recommends leaving this field blank. When left blank, the default path is used, which is the short name of the NetWorker server. If you do enter a path in this field, ensure that the path has NFS permissions. When you log in to the Data Domain resource, navigate to the NFS section and add the Mtree device path (the path to the NetWorker backup device) as a valid NFS path. 6. Click OK to save the changes

Related:

How are you collecting data from Windows Servers?

I am curious what people are doing for collecting logs from Windows Servers (2008, 2012, 2016). I have heard that if your environment has SMBv1 disabled the Microsoft Security Event Log protocol no longer functions.

Does anyone have experience they want to share with collecting Windows Server logs and if they have SMBv1 disabled?

Thanks,
Tim

Related: