PSSDIAG is a general purpose diagnostic collection utility that Microsoft Product Support Services uses to collect various logs and data files. PSSDIAG can natively collect Performance Monitor logs, SQL Profiler traces, SQL Server blocking script output, Windows Event Logs, and SQLDIAG output. 

PSSDIAG data collection utility on cloud. Overview. PSSDIAG is a general purpose diagnostic collection utility that Microsoft Product Support Services uses to collect various logs and data files. PSSDIAG can natively collect Performance Monitor logs, SQL Profiler traces, SQL Server blocking script output, Windows Event Logs, and SQLDIAG output. 

PSSDIAG data collection utility 

Applies to: SQL Server 

PSSDIAG is a general purpose diagnostic collection utility that Microsoft Product Support Services uses to collect various logs and data files. PSSDIAG can natively collect Performance Monitor logs, SQL Profiler traces, SQL Server blocking script output, Windows Event Logs, and SQLDIAG output. The data collection can be customized by enabling or disabling any of these log types, by changing the sample interval of the blocking script and the Performance Monitor logs, and by modifying the specific events and counters for SQL Profiler and Performance Monitor to capture. PSSDIAG can also run custom utilities or custom Transact-SQL scripts for support cases that require data outside the natively supported diagnostic types. 

This documentation applies to the version of PSSDIAG that Microsoft Product Support Services sends to assist with troubleshooting of support cases. A slightly different version of the tool is available for public download. For documentation that focuses on the public downloadable version of the tool, visit the following Microsoft Developer Network (MSDN) Web site: 

For Microsoft SQL Server 2005 and later versions, use the Pssdiag and Sqldiag manager that can be found on the following codeplex site: 

For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base: 

How to obtain Microsoft support files from online services 

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file. 

How to start PSSDIAG 

PSSDIAG expands into the C:\PSSDIAG folder that it creates on your computer. This folder will need to be on a drive that has sufficient disk space available to hold the data and the log files that PSSDIAG has been configured to capture. Because PSSDIAG can be configured to collect many different log types, the free disk space that is required may vary from a megabyte or two, up to several gigabytes. Be aware that sometimes the amount of trace data collected depends on the nature and the volume of the workload that the server is processing. Therefore, a precise estimate may not be possible. For data collection that involves high-volume trace types such as SQL Profiler tracing, make sure that PSSDIAG is run from a local drive, not from a network share or a from a mapped network drive.

Generally, you will run PSSDIAG locally on the server that is being monitored. However, you can configure PSSDIAG to monitor a remote server. For more information about how to run PSSDIAG remotely, see the “Running PSSDIAG remotely or on a clustered SQL Server” section of this article. Note that running PSSDIAG remotely means that the data collected and traced will be sent over the network to a remote computer. This could introduce moderate to significant impact on your SQL Server performance depending on the network bandwidth and speed as well as I/O and processing capability of the remote system where data is written.

Note You may have to perform an extra step if you are collecting data from a clustered instance of SQL Server. Make sure to read the “How to Run PSSDIAG Remotely or on a Clustered SQL Server” section of this article, if you are connecting to a clustered instance of SQL Server, even if PSSDIAG will be run locally on the server.

Pssdiag.exe does not have significant inherent security requirements. However, Microsoft Windows NT administrator credentials are required for many of the diagnostics that PSSDIAG can be optionally configured to capture. Also, you must have sysadmin credentials on SQL Server if PSSDIAG is to capture diagnostics from SQL Server (that is, if PSSDIAG is not running in a “generic” mode with the /G command-line switch). By default, PSSDIAG will make a Windows authenticated connection to SQL Server; however, you can use SQL Server authentication if you want. 

PSSDIAG supports several optional command-line parameters. For more information about the optional command-line parameters, see the “PSSDIAG Command Line Parameters” section. However, generally it is not necessary to use the optional parameters. After you have extracted the PSSDIAG files from the package on the Microsoft Download Center, run Pssdiag.exe to start the data collection.

When PSSDIAG starts, it first opens, and then configures the log files it has been configured to capture. This process may take several seconds. When PSSDIAG is fully started and all the logs are active, it will output the following message to the console:
  

PSSDIAG Collection started. Press Ctrl+C to stop. 

If you are running PSSDIAG to collect data about a problem that you can reproduce at will, wait until you receive the message before you try to reproduce the problem.

Do not log out of the console session where PSSDIAG is running before the data collection is complete, and PSSDIAG has been shut down. Because PSSDIAG is a console utility, not a service, logging out of the session where PSSDIAG is running will shut down the utility and end data collection. You can run PSSDIAG from a Terminal Server session if you want, and you can disconnect the session instead of logging out to leave PSSDIAG running. 

How to stop PSSDIAG 

To stop PSSDIAG, press CTRL+C in the console window where PSSDIAG is running. Note that it is also possible to instruct PSSDIAG to shut itself down automatically at a particular time. For more information about this, see the “Automatically Starting and Stopping PSSDIAG” section. If PSSDIAG is automatically adding files to a compressed .cab file, it may take quite a while for PSSDIAG to finish compressing the final log files. After you press CTRL+C, PSSDIAG will send a message, that is similar to the following, to the console:
  

PSSDIAG Ending data collection. wait while the process shuts down and files are compressed (this may take several minutes) 

After this message appears, PSSDIAG is no longer collecting additional data from your server, even though it may continue to compress previously collected data.

Before PSSDIAG shuts down completely, it may prompt you with a message similar to:

  

The files in F:\pssdiag\output\ have been added to PSSDIAG.CAB. Delete the backups in F:\pssdiag\output\backup\? 

When possible, Microsoft recommends that you answer with “N” to retain the collected data files in the Backup folderuntil you can confirmthat the Pssdiag.cab output file is intact.
  

Location of PSSDIAG output 

Unless you specify a custom output folder by using the /O command-line parameter, PSSDIAG creates a folder that is named Output in the folder where it is run. If you are running PSSDIAG with the /C0 (default) or the /C1 command-line parameters to disable automatic compression, the output files will remain in this folder. You may want to compress the Output folder with the tool of your choice if you have to upload the folder to a Microsoft support professional.

If PSSDIAG is operating in automatic compression mode, it will add all the output files to a compressed Pssdiag.cab file in the Output folder. By default, PSSDIAG will not perform any compression. After a file has been successfully added to the Pssdiag.cab file, it will be moved to a separate folder that is named Backup. The Backup folder is created in the Output folder. Note that the maximum amount of uncompressed data that can be added to a single CAB file is 2-gigabytes (GB). If the data collected exceeds 2 GB, additional CAB files named Pssdiag2.cab, Pssdiag3.cab, and so on, will be created.
  

Removing PSSDIAG 

PSSDIAG does not register any COM objects, copy any files to system directories, or modify the system registry. To remove PSSDIAG when data collection is complete, delete the folder that contains the PSSDIAG files. PSSDIAG does install several system stored procedures in the master database. These stored procedures are automatically removed when PSSDIAG shuts down.
  

PSSDIAG command line parameters :

You can run PSSDIAG /? from the command-line to see a list of the command-line parameters that PSSDIAG supports. The most frequently used parameters are described in the following table. All these command-line parameters are optional.
  

Parameter	Description
/Q	Quiet mode. Suppresses prompts that require user interaction, such as the prompt to delete the backup files.
/C#	/C0 disables automatic compression, and /C1 enables NTFS compression for files in the OUTPUT directory. /C0 (no compression) is the default.
/B  YYYYMMDD_HH:MM:SS	Specifies a future start time to start collection. PSSDIAG will remain idle until this time is reached. The date and time must be provided in the exact form that is specified here. The date and the time can be specified together or separately. For example, you can specify the time only or the date only.
/E  YYYYMMDD_HH:MM:SS	Specifies an automatic shutdown time. When this time is reached, PSSDIAG will automatically stop data collection and shut itself down. The date and the time can be specified together or separately. For example, you can specify the time only or the date only.
/G	Generic mode. PSSDIAG defaults to a SQL Server-centric data collection mode that requires a running instance of SQL Server. The /G parameter disables SQL Server-specific data collection, so that PSSDIAG can be used for other scenarios.

  

Automatically starting and stopping PSSDIAG :

Sometimes, it may be convenient to have PSSDIAG automatically start data collection at a specified time, or automatically stop after collecting data for a specified time. For example, you may be troubleshooting a problem that consistently appears at 2:00 am. In a case like this, you may want PSSDIAG to start data collection at 1:00 am, and to automatically shut down at 3:00 am. The easiest way to start and stop data collection automatically at a specified time is to use the /B and the /E command-line parameters. Make sure to use the exact date format for these parameters that is specified in the “PSSDIAG Command Line Parameters” section. The times must be specified relative to local time on the computer where PSSDIAG is running.

PSSDIAG will also shut down automatically whenever it finds a file named Pssdiag.stop in the utility’s output folder. This can be useful for situations when you want to programmatically shut down PSSDIAG after some event occurs, but you do not know in advance the time that this event will occur. The contents of the Pssdiag.stop file are irrelevant. One option is to use a command like the following in a batch file: 

ECHO abc > F:\PSSDIAG\Output\PSSDIAG.STOP 

  

Performance impact of PSSDIAG :

Because PSSDIAG is just a wrapper around other data collection APIs and utilities, the performance impact of running PSSDIAG is generally equal to the impact of the traces that PSSDIAG has been configured to capture. The same performance impact would be seen if the same trace data was captured manually, without using PSSDIAG.

PSSDIAG can be configured to capture a small amount of data or a large amount, and the type of data that is captured is typically customized for each incident. Because of this, it is not possible to make a general statement about the effect that running PSSDIAG may have without taking into account the log types and trace events that are being collected. If you are concerned about the potential impact of data collection on a server, contact the Support Professional that sent you PSSDIAG to clarify the diagnostic types that it has been configured to capture.

The one task that Pssdiag.exe performs directly that may consume significant CPU resources is the automatic compression of data files in CAB archives. By default, this feature is disabled. However, it can be enabled with the /C command-line parameter. The /C command-line parameter is discussed in detail in the “PSSDIAG Command Line Parameters” section.
  

Running PSSDIAG remotely or on a clustered SQL Server :

For PSSDIAG to collect data from a remote server or from a clustered instance of SQL Server, the Pssdiag.ini file must be modified. It must specify the name of the server that PSSDIAG should connect to. Tell the Support Professional you are working with the name of the server so that this can be configured correctly before PSSDIAG is sent to you.

If you are making this change yourself, locate the Pssdiag.ini file in the same folder as Pssdiag.exe. Open Pssdiag.ini in Notepad. The first line in the file contains the string “[.]”. Replace the period between the square brackets with the remote server’s name. If you are collecting data from a named instance of SQL Server, note that the server name is not the full name of the instance of SQL Server. For example, if the name of your instance of SQL Server is “MYSERVER\MyInstance“, you will replace the first line of the Pssdiag.ini file with “[MYSERVER]”.

SQL Profiler tracing is always performed on the server. Because of this, if PSSDIAG has been configured to collect Profiler data, there are additional complications involved with running PSSDIAG remotely. In these cases, Microsoft recommends that you run PSSDIAG locally on the server. If you want to consider the option of remote data collection when Profiler traces are required, ask the Support Professional you are working with for more details.  Again, the performance impact on SQL Server can be visible if this choice is made.

If the instance of SQL Server is clustered, use the virtual server name instead of the computer name of a cluster node.

Important You must always explicitly specify the virtual server name in the Pssdiag.ini file when you connect to a clustered instance of SQL Server, even when PSSDIAG will be run locally on one of the cluster nodes. 

The PSSDiag utility was originally created for SQL Server 7.0 and SQL Server 2000. A version was created and included with SQL Server 2005 and later builds. The new version is named SQLDiag and is included with SQL Server. For more information about SQLDiag, 

PSSDIAG data collection utility :

PSSDIAG is a general purpose diagnostic collection utility that Microsoft Product Support Services uses to collect various logs and data files. PSSDIAG can natively collect Performance Monitor logs, SQL Profiler traces, SQL Server blocking script output, Windows Event Logs, and SQLDIAG output. The data collection can be customized by enabling or disabling any of these log types, by changing the sample interval of the blocking script and the Performance Monitor logs, and by modifying the specific events and counters for SQL Profiler and Performance Monitor to capture. PSSDIAG can also run custom utilities or custom Transact-SQL scripts for support cases that require data outside the natively supported diagnostic types. 

 This documentation applies to the version of PSSDIAG that Microsoft Product Support Services sends to assist with troubleshooting of support cases. A slightly different version of the tool is available for public download. For documentation that focuses on the public downloadable version of the tool, visit the following Microsoft Developer Network (MSDN) Web site: 

For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base: 

 How to obtain Microsoft support files from online services :

Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file. 

How to start PSSDIAG 

PSSDIAG expands into the C:\PSSDIAG folder that it creates on your computer. This folder will need to be on a drive that has sufficient disk space available to hold the data and the log files that PSSDIAG has been configured to capture. Because PSSDIAG can be configured to collect many different log types, the free disk space that is required may vary from a megabyte or two, up to several gigabytes. Be aware that sometimes the amount of trace data collected depends on the nature and the volume of the workload that the server is processing. Therefore, a precise estimate may not be possible. For data collection that involves high-volume trace types such as SQL Profiler tracing, make sure that PSSDIAG is run from a local drive, not from a network share or a from a mapped network drive.

Generally, you will run PSSDIAG locally on the server that is being monitored. However, you can configure PSSDIAG to monitor a remote server. For more information about how to run PSSDIAG remotely, see the “Running PSSDIAG remotely or on a clustered SQL Server” section of this article. Note that running PSSDIAG remotely means that the data collected and traced will be sent over the network to a remote computer. This could introduce moderate to significant impact on your SQL Server performance depending on the network bandwidth and speed as well as I/O and processing capability of the remote system where data is written.

Note You may have to perform an extra step if you are collecting data from a clustered instance of SQL Server. Make sure to read the “How to Run PSSDIAG Remotely or on a Clustered SQL Server” section of this article, if you are connecting to a clustered instance of SQL Server, even if PSSDIAG will be run locally on the server.

Pssdiag.exe does not have significant inherent security requirements. However, Microsoft Windows NT administrator credentials are required for many of the diagnostics that PSSDIAG can be optionally configured to capture. Also, you must have sysadmin credentials on SQL Server if PSSDIAG is to capture diagnostics from SQL Server (that is, if PSSDIAG is not running in a “generic” mode with the /G command-line switch). By default, PSSDIAG will make a Windows authenticated connection to SQL Server; however, you can use SQL Server authentication if you want. 

PSSDIAG supports several optional command-line parameters. For more information about the optional command-line parameters, see the “PSSDIAG Command Line Parameters” section. However, generally it is not necessary to use the optional parameters. After you have extracted the PSSDIAG files from the package on the Microsoft Download Center, run Pssdiag.exe to start the data collection.

When PSSDIAG starts, it first opens, and then configures the log files it has been configured to capture. This process may take several seconds. When PSSDIAG is fully started and all the logs are active, it will output the following message to the console:
   PSSDIAG Collection started. Press Ctrl+C to stop. 

If you are running PSSDIAG to collect data about a problem that you can reproduce at will, wait until you receive the message before you try to reproduce the problem.

Do not log out of the console session where PSSDIAG is running before the data collection is complete, and PSSDIAG has been shut down. Because PSSDIAG is a console utility, not a service, logging out of the session where PSSDIAG is running will shut down the utility and end data collection. You can run PSSDIAG from a Terminal Server session if you want, and you can disconnect the session instead of logging out to leave PSSDIAG running. 

How to stop PSSDIAG 

To stop PSSDIAG, press CTRL+C in the console window where PSSDIAG is running. Note that it is also possible to instruct PSSDIAG to shut itself down automatically at a particular time. For more information about this, see the “Automatically Starting and Stopping PSSDIAG” section. If PSSDIAG is automatically adding files to a compressed .cab file, it may take quite a while for PSSDIAG to finish compressing the final log files. After you press CTRL+C, PSSDIAG will send a message, that is similar to the following, to the console:
  

2003/10/02 12:24:00.69 PSSDIAG Ending data collection. wait while the process shuts down and files are compressed (this may take several minutes) 

After this message appears, PSSDIAG is no longer collecting additional data from your server, even though it may continue to compress previously collected data.

Before PSSDIAG shuts down completely, it may prompt you with a message similar to:

  The files in F:\pssdiag\output\ have been added to PSSDIAG.CAB. Delete the backups in F:\pssdiag\output\backup\? 

When possible, Microsoft recommends that you answer with “N” to retain the collected data files in the Backup folderuntil you can confirmthat the Pssdiag.cab output file is intact.
  

Location of PSSDIAG output :

Unless you specify a custom output folder by using the /O command-line parameter, PSSDIAG creates a folder that is named Output in the folder where it is run. If you are running PSSDIAG with the /C0 (default) or the /C1 command-line parameters to disable automatic compression, the output files will remain in this folder. You may want to compress the Output folder with the tool of your choice if you have to upload the folder to a Microsoft support professional.

If PSSDIAG is operating in automatic compression mode, it will add all the output files to a compressed Pssdiag.cab file in the Output folder. By default, PSSDIAG will not perform any compression. After a file has been successfully added to the Pssdiag.cab file, it will be moved to a separate folder that is named Backup. The Backup folder is created in the Output folder. Note that the maximum amount of uncompressed data that can be added to a single CAB file is 2-gigabytes (GB). If the data collected exceeds 2 GB, additional CAB files named Pssdiag2.cab, Pssdiag3.cab, and so on, will be created.
  

Removing PSSDIAG 

PSSDIAG does not register any COM objects, copy any files to system directories, or modify the system registry. To remove PSSDIAG when data collection is complete, delete the folder that contains the PSSDIAG files. PSSDIAG does install several system stored procedures in the master database. These stored procedures are automatically removed when PSSDIAG shuts down.
  

PSSDIAG command line parameters :

You can run PSSDIAG /? from the command-line to see a list of the command-line parameters that PSSDIAG supports. The most frequently used parameters are described in the following table. All these command-line parameters are optional.
  

Parameter	Description
/Q	Quiet mode. Suppresses prompts that require user interaction, such as the prompt to delete the backup files.
/C#	/C0 disables automatic compression, and /C1 enables NTFS compression for files in the OUTPUT directory. /C0 (no compression) is the default.
/B  YYYYMMDD_HH:MM:SS	Specifies a future start time to start collection. PSSDIAG will remain idle until this time is reached. The date and time must be provided in the exact form that is specified here. The date and the time can be specified together or separately. For example, you can specify the time only or the date only.

 

Statistics and diagnostic data are the lifeblood of any effort. You can’t find out what’s wrong with a given database’s performance without hard numbers backing up your theories. That bottleneck in a table might not be due to an indexing issue; maybe it’s the way database files are allocated. This is where Pssdiag and Sqldiag Manager comes in. 

Microsoft bundles a command-line tool with SQL Server, called , for collecting diagnostic information from both SQL Server instances and the Windows system it’s running on. It can harvest quite a breadth of data: SQL Server Profiler traces and data about blockages, Windows performance and event logs and SQL Server configuration information. 

For more on SQL troubleshooting :

Sqldiag’s greatest disadvantage is that it’s not very interactive. It’s a command-line tool that uses an XML configuration file, which must be hand-edited. Although you can create multiple XML files for harvesting different batches of statistics, it’s still not the easiest way to go about working with the tool. This is even more true if you’re running Sqldiag as a service, which is handy for non-stop background collection of data but again requires a good deal of manual setup to be useful. If you find yourself constantly having to tweak the data-collection parameters, Sqldiag should be easier to set up and work with multiple times, not just once. 

Enter , an open source project that provides Sqldiag with a graphic interface. It’s not just for show: It makes it easier to create profiles for Sqldiag, and to package the program and its attendant files so that it can be run easily on multiple servers. 

Pssdiag and Sqldiag Manager (P&SM) works with all versions of SQL Server since version 7.0, including 2000, 2005 and 2008 (Support for Windows Server 2012 is planned as well). It also supports all SQL Server processor platforms – x86/x64 and Itanium – so it doesn’t matter which CPU or edition of the software you’re using. Note that if you’re using SQL Server 2000 or earlier, the necessary tools may have to be since they were not included in earlier editions of SQL Server. 

P&SM works by compiling a package—a CAB file that contains custom data-collection parameters you’ve specified. When you run P&SM, you compile a package by specifying an instance of SQL Server by name (the default is “*”, or all instances on the current machine), choosing the performance counters, log events and diagnostic data for both the entire machine and for SQL Server instances themselves. These parameters are compiled into a CAB file, which you then extract and run on the target machine. 

By default the most common and useful diagnostics are already pre-selected, although depending on the kinds of problems you’re looking for, you may want to narrow things down. It is recommended to use things like trace filtering to limit the scope of what’s captured, but also note that how this is implemented can reduce I/O and disk space usage at the cost of CPU—in essence, trading one problem for another. They give some specific recommendations for avoiding such issues; for example, filtering integer columns instead of text and not capturin, which may not provide useful insights in the first place. 

One of the most important things about P&SM is that it allows you   This is useful if the data you’re trying to collect isn’t being gleaned from one of the sources exposed through the P&SM interface. You could use the custom collectors to run T-SQL commands, batch scripts, PowerShell commands or third-party command-line utilities. The files produced by PS&M can be analyzed by hand or fed to another utility by the same author, SQL Nexus. 

There are a couple of other things about packages created by P&SM worth keeping in mind. First, when you run the trace package, it should be run on the same machine as the instance of SQL Server and monitored whenever possible. This is in part because you need the SQL Server instance itself to do some of the necessary capture work. The work of capturing those stats can’t be offloaded to another machine or instance. You can run the trace package on another machine only if you’re not capturing a SQL Server profiler trace, but the authors claim the benefits are minimal anyway, so it’s probably best to run the trace from the system in question and save yourself some hassle. 

In the same vein, you might be tempted to have the trace package from a network drive as a way to save yourself some trouble. For example, you can put the various trace packages all in subfolders on the same shared drive, and then run them from each SQL Server instance. Again, this is not recommended. The way I see it, the amount of network traffic back and forth to the drive in question may create an artificial performance drain and throw off the accuracy of the trace.

INSTALL AND CONFIGURE PSSDIAG:

 

PSSDIAG is a general purpose diagnostic collection utility that Microsoft Product Support Services uses to collect various logs and data files. PSSDIAG can natively collect Performance Monitor logs, SQL Profiler traces, SQL Server blocking script output, Windows Event Logs, and SQLDIAG output. The data collection can be customized by enabling or disabling any of these log types, by changing the sample interval of the blocking script and the Performance Monitor logs, and by modifying the specific events and counters for SQL Profiler and Performance Monitor to capture. PSSDIAG can also run custom utilities or custom Transact-SQL scripts for support cases that require data outside the natively supported diagnostic types.

PSSDIAG data collection utility on cloud for AWS

 

Major Features of PSSDIAG data collection utility 

• Powerful data collection capabilities:  The tool relies on SQLdiag collector engine to provide collection of perfmon, profiler trace, msinfo32, errorlogs, Windows event logs, TSQL script output and registry exports.
• Default templates: You can choose SQL Server version and platform (32 bit or 64 bit). The tool will automatically choose a default template for the combination. This will have default set of perfmon counters, profiler traces.
• Shipped with ready to use Custom collectors:  Most commonly used custom collectors include SQL Server 2005, 2008 or 2008 R2 performance collector.
• Customization/Extensibility:  You can customize what perfmon and profiler trace events you want to collect.   Additionally, you can create your own custom collectors with TSQL Scripts, batch files and utilities.   See customization guide.
• Packaging: With a single click of save, the tool will package all your files into a single cab so that you can ship to the machine where you intend to run on.
• Integration with SQL Nexus:  The custom collectors shipped will collect data that can be analyzed by SQL Nexus Tool.

 

• Installation Instructions For Windows

Installation Instructions For Windows

Note: How to find PublicDNS in AWS

Step 1) RDP  Connection: To connect to the deployed instance, Please follow Instructions to Connect to Windows  instance on AWS Cloud

1) Connect to the virtual machine using following RDP credentials:

• Hostname: PublicDNS  / IP of machine
• Port : 3389

Username: To connect to the operating system, use RDP and the username is Administrator.
Password: Please Click here to know how to get password .

Step 2) Click the Windows “Start” button and select “All Programs” and then point to PSSDIAG data collection utility 

Step 3) Other Information:

1.Default installation path: will be in your root folder “C:\Program Files (x86)\Microsoft\Pssdiag\”
2.Default ports:

• Windows Machines:  RDP Port – 3389
• Http: 80
• Https: 443

Configure custom inbound and outbound rules using this link

Installation Step by Step Screenshots

 

 

 

 

• Installation Instructions For Windows
• Installation Instructions For Ubuntu
• Installation Instructions For Redhat

Installation Instructions for Windows

Step 1) VM Creation:

1. Click the Launch on Compute Engine button to choose the hardware and network settings.

2.You can see at this page, an overview of Cognosys Image as well as estimated cost of running the instance.

3.In the settings page, you can choose the number of CPUs and amount of RAM, the disk size and type etc.

Step 2) RDP Connection: To initialize the DB Server connect to the deployed instance, Please follow Instructions to Connect to Windows instance on Google Cloud

Step 3) Database Login Details:

The below screen appears after successful deployment of the image.

For local MySQL root password, please use the temporary password generated automatically during image creation as shown above.

i) Please connect to Remote Desktop as given in step 2 to ensure stack is properly configured and DB is initialized.
ii) You can use MySQL server instance as localhost, username root and password as shown above.

If you have closed the deployment page you can also get the MySQL root password from VM Details  “Custom metadata” Section.

Step 3) Application URL:

 

 

 

 

 

Step 4) Other Information:

1.Default ports:

• Linux Machines:  SSH Port – 22

2. To access Webmin interface for management please follow this link

Installation Instructions For Redhat

Step 1) VM Creation:

1.Click the Launch on Compute Engine button to choose the hardware and network settings.

 

2.You can see at this page, an overview of Cognosys Image as well as some estimated costs of VM.

 

3.In the settings page, you can choose the number of CPUs and amount of RAM, the disk size and type etc.

 

Step 2) SSH Connection: To connect to the deployed instance, Please follow Instructions to Connect to Redhat instance on Google Cloud

1) Download Putty.

2) Connect to the virtual machine using SSH key

• Hostname: PublicDNS  / IP of machine
• Port : 22

Step 3) Database Login Details:

The below screen appears after successful deployment of the image.

For local MySQL root password, please use the temporary password generated automatically during image creation as shown above.

i) Please connect to Remote Desktop as given in step 2 to ensure stack is properly configured and DB is initialized.
ii) You can use MySQL server instance as localhost, username root and password as shown above.

If you have closed the deployment page you can also get the MySQL root password from VM Details  “Custom metadata” Section

Step 4)Application URL:

Steps to configure the stack:

 

 

Step 5 ) Other Information:

1.Default installation path: will be in your web root folder

2.Default ports:

Windows Machines: RDP Port – 3389
Http: 80
Https: 443
Mysql ports: By default, these are not open on Public Endpoints. Mysql :3306