Troubleshooting failed VDS actions
Contributors Download PDF of this page
Much of the logging that happens in VDS is not exposed in the web UI due to the sheer volume of it. More detailed logs are found on the end point. These logs are described below.
They are found in the Program Files path for VDS on the CWMGR1 server and in some cases on individual client VMs. This varies by VDS version, example include:
C:\Program Files\CloudWorkspace\ C:\Program Files\CloudJumper\ C:\Program Files\IndependenceIT\
File type also varies by VDS version, log files are either .txt or .log files found in sub-folders of the above outlined path.
CW VM Automation Service log
The CW VM Automation service is a Windows Service that is responsible for the management of all Virtual Machines in the deployment. As a Windows Service it is always running in a deployment, but has two main modes of operation: Scheduled Task Mode and Event Mode.
Scheduled Task Mode consists of activities that are performed on the VMs as part of a schedule, including collection sizing and performance data, rebooting VMs, checking on state (on or off) vs rule sets generated by the Workload Schedule and Live Scaling features. The logs denote these action types in the 5th column with names like “Daily Actions”, “Weekly Actions” and “Daily Maintenance”. If you are troubleshooting questions like “Why did Server X reboot last night at 2:00 am” or “Why is this server on when I think it should be off” then the scheduled tasks for those specific VMs are usually the best place to look.
Event Mode is activated when a user or other VDS Service such as the CW Automation Service asks for a Task to be completed. Examples of this type of activity include a user request to Create a new Server or CW Automation requesting the sizing and state of servers to be checked because more users were added to the workspace. These events typically have log entries with both the event name “Create Server” and the actual name of the VM right next to it (ex: Create Server NNXTS2). When troubleshooting these types of events, its usually best to scroll to the bottom of the log and then to an upwards search for the VM name. You can then scroll up more rows to see where the process started.
CW Automation Service log
The CW Automation Service log is the primary Windows services for managing the components of a Workspace deployment. It executes the tasks required to manage users, applications, data devices, and policy. In addition, it can create tasks for the CW VM Automation Service when changes need to be made to size, count, or state of the VMs in the deployment.
Like the CW VM Automation Service, the CW Automation service executes both scheduled tasks and event driven tasks, with the latter being the more frequent type. The log for the CW Automation Service starts each line with the entity and action being worked on (ex: Start Server NNXTS1) so searching for the entity name from the bottom of the file is the quickest way to find the specific log lines that apply to the task.
CW Agent Service log
The CW Agent Service performs all the tasks that are local to a specific VM, including checking the resource levels and utilization for the VM, checking that the VM has a valid certificate for TLS traffic, and checking to see if the mandatory reboot period has been reached. Besides checking on detail information on these tasks, this log can also be used to check for unexpected VM restarts or unexpected network or resource activity.
CWManagerX is a web service that provides the communication link between the local Deployment and the VDS global control plane. Tasks and data requests that originate in the VDS Web Application or VDS API are communicated to the local deployment through this web service. From there, the tasks and requests are directed to the appropriate web service (described above) or in rare cases directly to Active Directory. Since this is mostly a communications link there isn’t much logging that occurs during normal communication, but this log will contain errors when the communication link is broken or performing incorrectly.
DC Config log
DC Config is a Windows application that provides Deployment specific configuration parameters that are not exposed in the VDS Web Application interface. The DC Config log details the activities executed when configuration changes are made in DC Config.
CW vDC Deployment is a Windows application that performs the tasks necessary to create a Deployment in Azure. The log tracks the configuration of the Cloud Workspace windows services, default GPOs, and routing and resource rules.
The remaining logs track the installation of the Windows Services and application described above. Since VDS services auto-update when a new version is targeted at that specific deployment, these logs track the upgrade process since the Service or application typically needs to be off while being upgraded. If you find the Services are consistently Stopped these logs can help identify if a failed upgrade to a specific service is the cause. In these cases, we would expect to see an error in these logs detailing why the upgrade failed.
Accessing logs and reviewing information
VDS keeps detailed logs and exposes some of them on the Task History section of the Deployments page in VDS. Click on View can show details of the listed tasks.
Sometimes the Task History does not contain enough details to identify the true root cause. In order to keep the Task History section usable and not overwhelmed by all logged events, only a subset of task information is presented here. For a deeper look the text log files referenced above can provide more details.
To access this log, navigate to the Deployments Section and click the Gear Icon next to the CWMGR1 VM, then click Connect (or in the case of the CwAgent log, connect to the appropriate VM)
When connecting to a Platform Sever (Like the CWMGR1) you will not be automatically logged into the server (unlike connecting to a server in the tenant). You’ll need to login with a Level3 .tech account.
Then navigate to the path as shown above and open the log file.
This text file contains a log of all events, listed form oldest to newest:
When opening a support case with NetApp VDS, being able to provide the errors found here will SIGNIFICANTLY accelerate the speed to resolution.