#SQL Server WMI provider error
Explore tagged Tumblr posts
Text
Troubleshooting: SQL Server Config manager error: Cannot connect to WMI provider
If you’re encountering the “Cannot connect to WMI provider” error when trying to open SQL Server Configuration Manager, it’s a sign that there’s a hiccup in the communication between the Configuration Manager and the Windows Management Instrumentation (WMI) service. This error can be frustrating, especially when you need to manage your SQL Server services, network configuration, and server…
View On WordPress
#Fix SQL Configuration Manager#Resolve SQL WMI error#SQL Server Configuration troubleshooting#SQL Server connection issues#SQL Server WMI provider error
0 notes
Text
System Center Configuration Manager current branch 1810 KB4486457 available

System Center Configuration Manager current branch 1810 KB4486457 available.
Issues that are fixed
First wave issues Synchronization of Office 365 updates may fail after you update to Configuration Manager current branch, version 1810. Errors messages that resemble one of the following are recorded in the WSyncMgr.log file: ProcessFileManifest() failed to process O365 file manifest. Caught exception: System.Net.WebException: An exception occurred during a WebClient request. ProcessFileManifest() failed to process O365 file manifest. Caught exception: System.UriFormatException: Invalid URI: The URI scheme is not valid. The distribution point upgrade process may fail. This causes a block of additional content distribution to that server. Errors messages that resemble the following are recorded in the distmgr.log file: Failed to copy D:\SRVAPPS\Microsoft Configuration Manager\bin\x64\ccmperf.dll to \\{server}\SMS_DP$\sms\bin\ccmperf.dll. GLE = 32 All superseded updates are removed and no are longer applicable on a client, even before expiration. This issue occurs even if the Do not expire a superseded software update until the software update is superseded for 3 months option is enabled. Performance improvements have been made to the Data Replication Service for device discovery data. The second and successive phases of a deployment start automatically after the success of the first phase, regardless of start conditions. Phased deployment deadline behavior settings are inconsistent between the Create Phased Deployment Wizard and the Phase Settings properties. When you run a Servicing Plan after you select a Product Category, the filter is not added correctly. The Cloud Management Gateway (CMG) content service is not created correctly when the CMG role is added after you update to Configuration Manager current branch, version 1810. The No deployment package option is selected after you change the properties of an Automatic Deployment Rule (ADR). After this update rollup is applied, affected ADRs can be re-created and their properties changes without any further issue. The Configuration Manager Message Processing Engine (MPE) may not always process Active Directory discovery data when optional attributes are added. Errors that resemble the following are recorded in the SMS_Message_Processing_Engine.log: ERROR: Got SQL exception when handle discovery message. Exception: System.Data.SqlClient.SqlException (0x80131904): String or binary data would be truncated.~~ The Service Connection Tool (serviceconnection.exe) fails and you receive the following error message when you use the -connect parameter: ERROR: System.IO.Exception : The directory is not empty. A user without Full Administrator rights may be unable to create or edit Windows Defender ATP Policies, even when you add them to the Endpoint Protection Manager security role. The Prerequisite Installation Checker incorrectly gives the option to retry a site installation again. If a second retry is tried, the administrator must run the Configuration Manager Update Reset Tool (CMUpdateReset.exe) to resolve the issue. Processing of .bld files by the SMS_Notification_Manager component takes longer than expected. This leads to delays in processing data and a backlog of files in the \inboxes\bgb.box folder. After you update to Configuration Manager current branch, version 1810, remote SQL providers who use Microsoft SQL Server 2014 or an earlier version may not always query the database. Errors that resemble the following are recorded in the smsprov.log: *** User $' does not have permission to run DBCC TRACEON. The Software Updates Patch Downloader component retries updates, up to three times. These retries fail and return error code 404. Windows Server 2016 updates are displayed incorrectly as available when you schedule updates to a Windows Server 2019 operating system image. Searching for a user’s first or last name, or full name, returns no results from the Overview section of the Assets and Compliance node of the Configuration Manager console. This issue occurs even when full discovery data is available. Globally available release issues After you enable support for express installation files, content may not always download from Windows Server Update Services (WSUS) servers in the following scenarios: Configuration Manager client installation through Software Update Point Installing updates directly from WSUS Windows Feature on Demand (FOD) or Language Pack (LP) acquisition After you update to Configuration Manager current branch, version 1810, device enrollment can overwrite Windows telemetry collection values that were previously set by Group Policy. This issue can cause value toggling between full and basic, for example, when Group Policy is applied. Hardware inventory is updated to include information about add-ins for Office365 and standalone Office products. Desktop Analytics deployment plans show a larger device count in the Configuration Manager console than in the Desktop Analytics Portal. Configuration Manager client setup may fail over a metered (for example, cellular) network connection. This may occur even if client policy settings allow for those connections. An error message that resembles the following is recorded in the Ccmsetup.log file on the client: Client deployment cannot be fulfilled because use of metered network is not allowed. Client setup may fail because of SQL Server CE schema changes. Errors that resemble the following are recorded in the Ccmsetup-client.log on the client: MSI: Setup was unable to compile Sql CE script file %windir%\CCM\DDMCache.sqlce. The error code is 80040E14. If an application is in a partly compliant state, and the client sees that a dependency is installed but the main application is not and requires re-enforcement, available deployment causes the following issues: The application is displayed as required or past due even though the deployment is available and there is no supersedence relation. Clicking Install has no effect. Sign in to Azure services fails when you use the Create Workflow in the Azure Services Wizard, even when correct credentials are used. Configuration Manager setup may fail the prerequisite check during installation or an update of a site server. This issue occurs if the environment uses SQL Always On. The “Firewall exception for SQL Server” rule shows a status of failed, and errors messages that resemble the following are recorded, even if the correct firewall exceptions are configured: ERROR: Failed to access Firewall Policy Profile. ERROR: Failed to connect to WMI namespace on Firewall exception for SQL Server; Error; The Windows Firewall is enabled and does not have exceptions configured for SQL Server or the TCP ports that are required for intersite data replication. The alternative download server that is listed in the "Specify intranet Microsoft update service location" window is not propagated to the Group Policy settings on the client. The download of Office 365 updates, such as “Semi-annual Channel Version 1808 for x86 Build 10730.20264” or “Monthly Channel Version 1812 for x64 Build 11126.20196” may fail. No errors are logged in the Patchdownloader.log file. However, entries that resemble the following are logged in the AdminUI.log log: (SMS_PackageToContent.ContentID={content_ID},PackageID='{package_ID}') does not exist or its IsContentValid returns false. We will (re)download this content. Read the full article
1 note
·
View note
Text
Download Wm320 Wireless Data Device Driver
Download Wm320 Wireless Data Device Driver Windows 10
Download Wm320 Wireless Data Device Driver Updater
Download Wm320 Wireless Data Device Driver
Download Wm320 Wireless Data Device Drivers
Then download the latest driver for your Intel® Wireless Adapter. For driver-only package, see IT Administrator Links for Intel® PROSet/Wireless Software. Manually install drivers and software. Once drivers downloaded, proceed with the following steps to manually install your drivers or Intel® PROSet/Wireless Software. Microsoft® ODBC Driver 13.1 for SQL Server® - Windows, Linux, & macOS The Microsoft ODBC Driver for SQL Server provides native connectivity from Windows, Linux, & macOS to Microsoft SQL Server and Microsoft Azure SQL Database.
DescriptionTypeOSVersionDateIntel® Wireless Bluetooth® for IT Administrators
This download record is recommended for IT administrators and includes Intel® Wireless Bluetooth® version 22.20.0 distribution packages.
DriverWindows 10, 32-bit* Windows 10, 64-bit*22.20.0 Latest1/12/2021Intel® PROSet/Wireless Software and Drivers for IT Admins
This download record is recommended for IT administrators, which includes driver-only and Intel® PROSet/Wireless Software version 22.20.0 distribution packages.
DriverWindows 10, 32-bit* Windows 10, 64-bit* Windows 8.1, 32-bit* 3 more22.20.0 Latest1/12/2021Intel® Wireless Bluetooth® for Windows® 10
Installs Intel® Wireless Bluetooth® version 22.20.0. Driver version varies depending on the wireless adapter installed.
DriverWindows 10, 32-bit* Windows 10, 64-bit*22.20.0 Latest1/12/2021Windows® 10 Wi-Fi Drivers for Intel® Wireless Adapters
This download record installs the Windows® 10 WiFi package drivers 22.20.0 for the AX210/AX200/9000/8000 series Intel® Wireless Adapters.
DriverWindows 10, 32-bit* Windows 10, 64-bit*22.20.0 Latest1/12/2021Intel® PROSet/Wireless Software and Drivers for Windows 7*
This download record installs Intel® PROSet/Wireless WiFi Software 21.40.5 including driver for Windows 7*. Driver version may differ depending on the wireless adapter installed.
DriverWindows 7, 32-bit* Windows 7, 64-bit*21.40.5 Latest2/18/2020Intel® PROSet/Wireless Software and Drivers for Windows 8.1*
This download record installs Intel® PROSet/Wireless WiFi Software 21.40.5 including driver for Windows 8.1*. Driver version may differ depending on the wireless adapter installed.
DriverWindows 8.1, 32-bit* Windows 8.1, 64-bit*21.40.5 Latest2/18/2020Intel® Wireless Bluetooth® for Windows 7*
This download record installs Intel® Wireless Bluetooth® version 21.40.5 and driver. Driver version varies depending on the wireless adapter and Windows* OS installed.
DriverWindows 7, 32-bit* Windows 7, 64-bit*21.40.5 Latest1/15/2020Intel® Wireless Bluetooth® for Windows 8.1*
This download record installs Intel® Wireless Bluetooth® version 21.40.5 and driver. Driver version varies depending on the wireless adapter and Windows* OS installed.
DriverWindows 8.1, 32-bit* Windows 8.1, 64-bit*21.40.5 Latest1/15/2020Intel® PROSet/Wireless Software and Drivers for Intel® Wireless 7260 Family
This download record contains the latest Intel® PROSet/Wireless Software and drivers available for Intel® Wireless 7260 Family.
DriverWindows 10, 32-bit* Windows 10, 64-bit* Windows 8.1, 32-bit* 5 moreLatest Latest5/21/2019Intel® Wireless Bluetooth® for Intel® Wireless 7260 Family and Intel® Dual-Band Wireless-AC 3160
This download record contains the latest Intel® Wireless Bluetooth® (including drivers) available for Intel® Wireless 7260 Family and Intel® Dual-Band Wireless-AC 3160.
DriverWindows 10, 32-bit* Windows 10, 64-bit* Windows 8.1, 32-bit* 5 moreLatest Latest5/21/2019Intel® PROSet/Wireless Software and Drivers for Intel® Dual Band Wireless-AC 3160
This download record contains the latest Intel® PROSet/Wireless Software and drivers available for Intel® Dual Band Wireless-AC 3160.
DriverWindows 10, 32-bit* Windows 10, 64-bit* Windows 8.1, 32-bit* 5 moreLatest Latest5/21/2019Intel® PROSet/Wireless Software and Drivers for Intel® Wireless 7265 Family (Rev. C)
This download record contains the latest Intel® PROSet/Wireless Software and drivers available for Intel® Wireless 7265 Family (Rev. C).
DriverWindows 10, 32-bit* Windows 10, 64-bit* Windows 8.1, 32-bit* 5 moreLatest Latest5/21/2019Intel® Wireless Bluetooth® for Intel® Wireless 7265 Family (Rev. C)
This download record contains the latest Intel® Wireless Bluetooth® (including drivers) available for Intel® Wireless 7265 Family (Rev. C).
DriverWindows 10, 32-bit* Windows 10, 64-bit* Windows 8.1, 32-bit* 5 moreLatest Latest5/21/2019
-->
The Windows Driver Model (WDM) provider grants access to the classes, instances, methods, and events of hardware drivers that conform to the WDM model. The classes for hardware drivers reside in the rootwmi namespace.
The WDM provider is of interest to those who write device drivers and to administrators who are interested in device driver data.
The following sections are discussed in this topic:
Information for Device Driver Writers
WMI classes related to a specific device driver are created when the WDM provider extracts the binary MOF from the device driver executable file. This takes place whenever WMI is started, a new device driver is installed, or the instance of WMIBinaryMofResource for a particular driver is deleted. By checking Wmiprov.log, you can determine if an error resulting in failure occurred while extracting the binary MOF file. Details of mofcomp errors are reported in Mofcomp.log. For more information, see WMI Log Files. For performance reasons, the WDM provider does not generate events while creating or deleting classes due to a WDM provider starting or stopping.
The WDM provider transforms all WNODE data into class information. If an error is encountered when transforming the data from WNODE to class data, it is reported in Wmiprov.log with the header formatted and bytes rendered in the same form as a memory dump.
Download Wm320 Wireless Data Device Driver Windows 10
Changes made to driver security settings do not take effect until the WDM provider is unloaded and reloaded. For more information, see Unloading a Provider.

WMI can also make high-performance counters for hardware drivers available. For more information about creating high-performance classes and displaying data in Perfmon System Monitor, see Improving the Efficiency of an Instance Provider. For more information about writing WMI-enabled device drivers, see https://www.microsoft.com/ddk. For more information about WDM specific qualifiers in the MOF file, see Qualifiers Specific to the WDM Provider.
Information for Administrators and Users of Driver Data
Listing the instances of the WMIBinaryMofResource class provides a list of the drivers in the system and information about whether the WDM provider succeeded in compiling the MOFs for each driver. You can force the provider to recompile and regenerate the classes for a driver by deleting the instance of WMIBinaryMofResource that represents that driver. Details of mofcomp errors are reported in the Mofcomp.log.
Download Wm320 Wireless Data Device Driver Updater
If the WMI namespace is corrupted, it can be deleted and reopened to force WDM to rebuild the driver classes. For more information about opening a namespace, see Creating Hierarchies Within WMI.
Driver classes can occasionally get 'stranded' if driver loading is interrupted or other abnormal operations occur. The WDM provider will only search for and clean up 'stranded' classes when a new driver is installed or when the SoftwareMicrosoftWBEMWDMProvider registry key value ProcessStrandedClasses is set to TRUE. Setting this value to TRUE slows WMI startup performance because of the cleanup operation. The default value is FALSE. The WDM provider only checks this registry value when the 'RootWmi' namespace is opened for the first time.
Download Wm320 Wireless Data Device Driver
If security changes are made to a WDM device driver, the changes will not go into effect until the WDM provider is unloaded and reloaded. The Windows Management service must be stopped and restarted to accomplish this.
Download Wm320 Wireless Data Device Drivers
Related topics
0 notes
Text
Mi Browser Pro - Video Download, Free, Fast&Secure
Mi Browser Pro – Video Download, Free, Fast&Secure
Mi Browser is a fast and secure full-featured web browser for mobile devices. Top performance and amazing user experience allow you to surf the web, use search, watch videos, shop online, and play games. Additional trendy features, such as downloading images and videos from social media, file management tools, and private folder, will have all your needs covered!
Given our goal of providing…
View On WordPress
#mi 4a pro browser#mi 4c pro browser#mi browser download problem#mi browser pro apk#mi browser problem#mi tv 4a pro browser#mi tv 4a pro web browser#sql server browser wmi provider error#xiaomi mi 9 pro default browser#xiaomi mi 9t pro standard browser ändern
0 notes
Text
Original Post from Security Affairs Author: Pierluigi Paganini
Researchers at Guardicore Labs reported that the Smominru botnet is rapidly spreading and now is already infecting over 90,000 machines each month around worldwide.
In February 2018, researchers from Proofpoint discovered a huge botnet dubbed ‘Smominru’ that was using the EternalBlue exploit to infect Windows computers and recruit them in Monerocryptocurrency mining activities. According to the researchers, the Smominru botnet has been active at least since May 2017 and at the time of its discovery infected more than 526,000 Windows computers.
According to a new report published by the researchers at Guardicore Labs, the Smominru, is rapidly spreading and now is already infecting over 90,000 machines each month around worldwide.
The report published by Guardicore Labs researchers analyzes the attack chain and the nature of the victims.
Experts discovered that many machines recruited in the botnet were reinfected even after removing the Smominru, a circumstance that suggests that these systems remain unpatched since first infection.
“During August, the Smominru botnet infected 90,000 machines around the world, with an infection rate of 4,700 machines per day. Countries with several thousands of infected machines include China, Taiwan, Russia, Brazil and the US.” reads the report published by the experts.
Most of the infected systems are Windows 7 and Windows Server 2008, representing 85 percent of all infections, in China, Taiwan, Russia, Brazil and the US.
In just one month, the worm infected more than 4,900 networks, some of them had dozens of internal machines infected. The largest network belongs to a healthcare provider in Italy, experts observed a total of 65 infected hosts.
Once compromised the system, a first-stage Powershell script named blueps.txt is downloaded onto the machine. This script performs the following actions:
It downloads and executes three binary files;
It creates a new administrative user named admin$ on the system;
It downloads additional scripts to perform malicious actions.
Once gained access to the targeted systems, Smominru installs a Trojan module and a cryptocurrency miner and attempt to infect other machines inside the target network.
The botnet main purpose continues to be crypto-mining but recently experts observed that operators added a data harvesting module and Remote Access Trojan (RAT) to their botnet’scryptocurrency mining code.
The latest variant of Smominru downloads and runs at least 20 distinct malicious scripts and binary payloads, including a worm downloader and an MBR rootkit.
The storage infrastructure is widely distributed, experts found more than 20 servers, each of them serves a few files and each file references additional 2-3 servers.
Operators stored many of the files on more than one hosting server, to improve the resilience of attack infrastructure to takedowns and its flexibility.
Most of the machines are located in the US, with some hosted by ISPs in Malaysia and Bulgaria.
“The attackers create many backdoors on the machine in different phases of the attack. These include newly-created users, scheduled tasks, WMI objects and services set to run at boot time.”continues the report.”The MS-SQL attack flow includes a unique persistence method; the attackers use the obscure task scheduling engine inside MS-SQL to run jobs at different time intervals, e.g. upon reboot, every 30 minutes, etc. “
Guardicore Labs experts managed to gain access to one of the attackers’ servers and analyzed its content to gather information on the nature of the victims.
“The attackers’ logs describe each infected host; they include its external and internal IP addresses, the operating system it runs and even the load on the system’s CPU(s). Furthermore, the attackers attempt to collect the running processes and steal credentials using Mimikatz,” the researchers say. continues the report.
Unlike previous variants, the new Smominru bot also removes infections from compromised systems and blocking TCP ports (SMB, RPC) to prevent infections by other threat actors.
Further data, including Indicators of Compromise, are reported in the analysis published by the experts.
window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = "3121199";
try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag("762221962", "300x250", "762221962"); }); } catch (error) {}
Pierluigi Paganini
(SecurityAffairs – APT, hacking)
The post Smominru Botnet continues to rapidly spread worldwide appeared first on Security Affairs.
#gallery-0-6 { margin: auto; } #gallery-0-6 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-6 img { border: 2px solid #cfcfcf; } #gallery-0-6 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Pierluigi Paganini Smominru Botnet continues to rapidly spread worldwide Original Post from Security Affairs Author: Pierluigi Paganini Researchers at Guardicore Labs reported that the Smominru…
0 notes
Text
PRTG Sensor Condensing With PowerShell
If you are an administrator in an enterprise environment there is a good change you know about PRTG Network Monitoring. This is a great application for monitoring all kinds of application data, resource usage, whatever you heart desires data for devices in a network. It has an auto-discovery feature that recommends sensors and discovers new devices. When PRTG recommends sensors they typically monitor one thing. The licensing is mostly based on how many sensors you have paid for. When you start reaching your limit and the budget is tight because the IT department is short on funds this may be a solution for you. The sensor I made for this purpose can be found on my GitHub page HERE.
The PRTG sensors that monitor CPU, Memory, and Disk Space use Windows Management Instrumentation (WMI). WMI is being replaced with the Common Information Model (CIM) in Windows devices. WMI was Microsofts original interpretation of CIMv2. CIM is a vendor-independent standard for describing the hardware and OS components of computer systems and providing tools that a program can use to both read and modify components. Remote Management using WMI is considered a security risk and should be avoided when possible. Info on that wil lbe for another blog. These are some of the many reasons I use CIM whenever possible. Why would Windows change the way they identify objects inside their Object Based Operating System you ask? Great question.
The only real thing the CIM cmdlets can’t do that WMI can is access amended qualifiers such as the class description. Many classes do not set this attribute which has not been a hardship for me at least. The way WMI is set up, combined with the length of time it has been around has caused the names of objects to be duplicated. This means different namespaces contain classes and instances with the same name which can get confusing and cause scripts to respond in unintended ways. CIM eliminates this issue as well as a few other bullet points I placed below.
Use of WSMAN for remote access (This means no more DCOM errors. You can drop back to DCOM for accessing systems with WSMAN2 installed)
Use of CIM sessions allows for accessing multiple machines
Get-CIMClass can be utilized for investigating WMI classes
Improves dealing with WMI associations
The phenomenally detailed documentation at PRTG for creating Custom Sensors can be found HERE. The way these sensors work with PRTG is a bat script or a ps1 script are run. The results are than placed into an XML format the PRTG Server interprets and displays for the admin monitoring the network devices. The sensor at my GitHub page is considered and EXE/Advanced Custom Sensor because it returns the XML output where as a Standard EXE sensor only returns a single true or false result. The PRTG sensors are usually only monitoring one thing because we do not want to overload a sensor with information. The max amount of sensor result fields allowed was somewhere between 50 and 60. That is an easy number to stay under however if CPU usage gets to high, inaccurate results may be produced.
In the code below what we are doing is creating a CIM Session to a remote device and running three commands inside that CIM Session as opposed to opening a session, issue the command, close the session three separate times. This will save us time and resources. We are using a CIM Session and not a PsSession because CIM sessions add the security of not allowing execution of arbitrary commands and return arbitrary objects. They also provide a unique benefit of taking up fewer system resources. CIM sessions stay dormant in the background of a Windows PowerShell session until an instruction is received.
$CimSessionOptions = New-CimSessionOption -UseSsl
$CIMSession = New-CimSession -ComputerName $Device -SessionOption $CimSessionOptions
$OS = Get-CimInstance -CimSession $CIMSession -ClassName "Win32_OperatingSystem"
$CPUs = Get-CimInstance -CimSession $CIMSession -ClassName "Win32_Processor"
$Disks = Get-CimInstance -CimSession $CIMSession -ClassName "Win32_LogicalDisk" | Where-Object -Property 'DriveType' -eq 3
SIDE NOTE: If your environment is not configured to use WinRM over HTTPS you should look at doing that. It allows you to use the -UseSsl parameter with ease and in many other cases where you want to ensure there is an extra layer of encryption protecting any information going over the wire.
You may have noticed above that the variable $Device is used in the -ComputerName parameter. If we were creating a PowerShell module it is best practice to use $ComputerName as the variable name. I did this because PRTG expects certain placeholder values to be set. If I renamed that variable to $ComputerName the PRTG sensor would fail to connect to the remote host. More info on that can be found HERE. When adding the custom sensor in PRTG we need to enter the place holder value in the following format.
'%device'
In the ps1 file, the $Device parameter is set and will be matched to the value of the device name. If you use Auto-Discover in PRTG you may need to rename some of the devices as Auto-Discover will name things with an extra extension such as [Windows SQL Server] or something along those lines. That entire name gets placed into the $Device variable which means the sensor is trying to contact a device that doesn't exist. An Example of how this is entered can be seen below.
'Write EXE result to disk' is selected as this is great for troubleshooting any issues that may be happening with the sensor. The latest result is always logged on the PRTG server in the following directory. C:\ProgramData\Paessler\PRTG Network Monitor\Logs (Sensors). This is extremely handy when trying to format your XML labels with the correct names and values. If you set a value of Bytes to become Gigabytes you will still see the Bytes value in this log file. This is because PRTG converts these values in their web application and not the XML parser.
Mutex Name is a great section they added. When you have a script running on multiple remote devices, you want there to be a limit on how many can run at once otherwise they might all run at once. Any devices that have a Mutex Name of R5 will run together. Any devices with a sensor that has a Mutex Value of DirkaDirka will run together. This way you are able to define how many instances of the script can be run at once.
After creating the EXE/Advanced sensor you will need to place it in the C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML directory. This way it will be available when you go to create the sensor and select it from a drop down menu inside the PRTG application. Once all is said and done my sensor will return results that look like the image below.
We are able to set the Warning and Alert values using the XML format defined by PRTG. The XML does need to be beautified in order for the sensor to work correctly. The below is a PowerShell function that I used to beautify the output.
There are a few fields that are commented out that can easily be added to the PRTG final sensor by just copying them from the comments inside the $XML variable between tags. I left out the below fields but feel free to add them and add your own Error and Warning limits if desired. It is very fun.
Read official blog post here: https://roberthosborne.com/f/prtg-sensor-condensing-with-powershell
0 notes
Link
As a proactive database administrator, one of your main tasks is monitoring different activities happening in your SQL Server instances continuously.
SQL Server provides us with the ability to automate such monitoring tasks and respond with the proper action, or, at a minimum, notify the related person, when a specific error, such asa performance issue or a Windows event is detected. Automated monitoring and response to the different SQL Server, performance or Window events is performed using the SQL Server Agent Job Alerts.
SQL Server Agent Job Alerts Overview
SQL Server Agent benefits from the different Windows and SQL Server events that are written to the Windows Application logs in the server by reading these events to find a match between these events and the defined alerts. When a match is found, a defined alert will be fired, and the response action will be executed.
To create an alert, you need to provide a meaningful name of the alert, less than 128 characters, the type of the event that will fire this alert and finally the action that will be performed by the SQL Server Agent as a response to that event. In addition, you should be member of SYSADMIN fixed server role to be able to run the sp_add_alert system stored procedure and create the alert.
There are three types of alerts that can be created in the SQL Server Agents:
SQL Server Event Alerts: This alert will be fired when an event with a specific error number or an error severity level occurs
SQL Server Performance Event Alerts: This alert will be fired when a specific performance counter exceeds, equal to or falls below a predefined threshold value
WMI event alerts: This alert will be fired when a specific Windows Management Instrumentation (WMI) event occurs
In this article, we will concentrate on creating and configuring alerts for SQL Server Agent jobs using ApexSQL Job.
ApexSQL Job can be downloaded from the ApexSQL download center and installed to your machine easily, by following a straight-forward installation wizard, in which you will be asked to provide the installation path only.
Getting started
After installing ApexSQL Job to your machine, click on its “job organization bag” icon to start using it in configuring the SQL Server Agent alerts. To add a new SQL Server instance, click on the Add button, from the SQL Server tasks category, under the Home tab, as shown below:
In the displayed Add SQL Server windows, provide the name of the SQL Server instance that you will connect to, and the authentication method and credentials that will be used to connect to the provided SQL Server instance, as follows:
As ApexSQL Job can be used to organize SQL Server Agent jobs, schedules and alerts on multiple instances at the same time, it organizes the different SQL Server instances within folders. So that, when a new SQL Server instance is added, you will be asked to add that instance under an existing folder, or create a new folder, as shown below:
After adding the SQL Server instance, you need to make sure that the SQL Server Agent service is up and running. To do that, click on the Start button, from the Agent tasks category, under the Home tab. If the service is already running, it will perform no action except for notifying that it is already running, as below:
And if the SQL Server Agent service is stopped, it will start the service and notify you with that action as follows:
In ApexSQL Job, there is a separate tab for creating, editing and deleting the different types of SQL Server Agent Job Alerts, as shown below:
ApexSQL Job allows you to create the three SQL Server Agent Alerts types described previously. To make it clear, we will discuss one example per each alert type using the ApexSQL Job:
SQL Server Event Alert
SQL Server Event Alert type is useful when you plan to perform a specific action in response of receiving a specific SQL error number or error severity level.
To create a new alert, click on the Add button, under the Alerts tab, and the Create alert window, will be displayed. The Create alert window will ask you to provide an indicative name for the alert, enable or disable that alert, and the type of the alert to be created. In this example, we will choose SQL Server Event Alert type, as below:
Under the SQL Server Event Alert type, you will have the option to specify the database on which this alert will be applied and if the alert will be fired in response to a specific SQL Server error number or error severity level.
For example, if you plan to monitor the failed logins in the SQL Server instance, configure the alert to be raised based on the error number 18456 occurrence. For more information about the different error numbers that can be received in SQL Server Engine, check the SQL Server error codes list.
ApexSQL Job allows you also to configure the alert to be raised based on different error severity levels, as shown below:
For example, you can monitor the failed logins by configuring the alert to be raised based on error severity 014 – Insufficient Permission, as below:
You have the option also to configure the alert to be fired if an error that contains a particular text in the event message is occurred, in case you recall part of the message text.
After configuring on which basis the alert will be fired, you will be asked to specify what action should be performed as a response for the occurred event. On the Create Alert window, click on the Response page to configure the response type, as follows:
From the Response page, you can see that there are two types of responses for the event occurrence:
Execute job: Select which SQL Server Agent job will be executed in response to the event occurrence
Notify operators: Provide a predefined operator or create a new operator to notify when the alert event occurred. Operators enable notification and monitoring capabilities of SQL Server Agent, by monitoring the different aspects of the SQL Server Engine and notify the administrators using email notification, pager email notification or net send notification. Check Operators for more information
In our example, we will execute a SQL Agent Job that logs all failed logins when an error with severity 14 is received.
In the Options page of the Create Alert window, you can optionally specify what will be included in the notification message, and how much time the two consequent responses will be delayed, as shown below:
Once created, the alert can be configured, monitored or deleted from the Alerts tab:
The same alert can be also created, checked and configured from the Jobs tab of the SQL Server Agent Job properties, where you can find the previously created alert on the related SQL Agent job, as follows:
If we simulate a number of failed login attempts, then check the target job history, from the History tab. ApexSQL Job you will see that the job is executed after being invoked by Alert 2, as shown below:
In addition, you can check how many times this alert occurred, when the last time this alert was fired and when the last response for the firing event occurred, from the History tab of the created alert, that will appear after creating the alert, with the ability to reset the occurrences count, as follows
SQL Server Performance Condition Alert
This type of alerts is raised in response to a specific performance condition. Where you specify the performance counter that you plan to monitor and a monitoring threshold for that counter.
To create a SQL Server performance condition alert, click on the Add button under the Alerts tab. In the Create Alert window, specify an indicative name for the alert, specify to enable or disable that alert, and specify the type of the alert to be SQL Server performance condition alert, as below:
In the Performance condition alert definition section, provide the Object as the area of performance to be monitored, from the available options below:
After specifying the performance area, select the performance counter from the counters list, that you plan to monitor. In addition, specify the threshold, a number describes that selected counter for the alert, and the behavior of the counter that fires the alert. For example, the alert can be fired if the current counter value rises above, becomes equal to or falls below the defined counter threshold.
In our example, we will monitor if the number of created transactions in the connected SQL Server instance exceeds 100 transactions. And as a response, we will execute a SQL Agent job that takes a transaction log backup for the users’ database to prevent running the transaction log file out of free space, as shown below:
After performing heavy load of transactions on the monitored SQL Server instance, you will see that the transaction log backup job is executed successfully after being invoked by the Alert 5, as shown below:
In addition, you can check how many time this alert occurred, when the last time this alert fired and when the last response for the firing event occurred, from the History tab of the created alert, with the ability to reset the occurrences count, as below:
WMI Event Alert
The functionality of SQL Server Agent alerts extends the scope of monitoring the SQL Server events, by allowing you to fire an alert in response to a particular Windows event.
To create WMI event alert, click on the Add button under the Alerts menu. In the Create alert window, specify an indicative name for the alert, specify to enable or disable that alert, and specify the type of the alert to be WMI event alert, as below:
In the WMI event alert definition section, specify the Namespace, where the SQL Server Agent will register itself as a WMI client, on the same computer where it is running, to the WMI Namespace provided to query for the event. In addition, specify the Windows Management Instrumentation Query Language statement, also known as WQL, that will be used to identify a specific event.
In our example, we will create an alert that is raised based on the DDL changes, such as ALTER DATABASE statement, on the connected instance. If any DDL change is performed, the alert will be fired and respond by executing a SQL Server Agent Job that audits these changes to an auditing repository, as shown below:
After executing number of ALTER DATABASE statements on the monitored SQL Server instance, you will see that the Log_DB_Changes job will be executed successfully after being invoked by the Alert 8, as shown below:
Again, the number of times this alert occurred, the last time this alert fired and the last response for the raised event occurrence, can be checked from the History tab of the created alert, with the ability to reset the occurrences count, as below:
0 notes
Text
DSC Resource Kit Release January 2017
We just released the DSC Resource Kit!
This release includes updates to 7 DSC resource modules, including 10 new DSC resources. In these past 6 weeks, 71 pull requests have been merged and 37 issues have been closed, all thanks to our amazing community!
The modules updated in this release are:
AuditPolicyDsc
xDismFeature
xExchange
xNetworking
xPSDesiredStateConfiguration
xSQLServer
xWebAdministration
For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.
xHyper-V has changes to be released, but the tests have a few issues at the moment. We will release it as soon as those issues are resolved. PSDscResources does not currently have any changes to release, but there are some changes queuing up. We will release it again soon once those changes are ready. We will update this blog post when either of these modules is released.
A new version of xActiveDirectory was also released about two weeks ago with some bug fixes for xADDomain and xADDomainController.
Our last community call for the DSC Resource Kit was last week on January 18. A recording of our updates as well as summarizing notes are available. Join us next time at 9AM PST on March 1 to ask questions and give feedback about your experience with the DSC Resource Kit. Keep an eye on the community agenda for the link to the call agenda.
We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!
All resources with the ‘x’ prefix in their names are still experimental – this means that those resources are provided AS IS and are not supported through any Microsoft support program or service. If you find a problem with a resource, please file an issue on GitHub.
Included in this Release
You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or Changelog.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).
Module Name Version Release Notes AuditPolicyDsc 1.1.0.0
Added the AuditPolicyCsv resource.
xDismFeature 1.2.0.0
xDismFeature: Resource no longer includes the Source parameter when it is not specified
Converted appveyor.yml to install Pester from PSGallery instead of from Chocolatey.
xExchange 1.13.0.0
Fix function RemoveVersionSpecificParameters
xExchMailboxServer: Added missing parameters except these, which are marked as “This parameter is reserved for internal Microsoft use.”
xNetworking 3.2.0.0
Fixed typo in the example”s Action property from “Blocked” (which isn”t a valid
value) to “Block”
Added support for auto generating wiki, help files, markdown linting
and checking examples.
Added NetworkingDsc.ResourceHelper module based on copy from PSDscResources.
MSFT_xFirewall:
Cleaned up ParameterList table layout and moved into a new file
(MSFT_xFirewall.data.psd1).
Separated Localization strings into strings file.
Added standard help blocks to all functions to meet HQRM standards.
Added CmdletBinding attribute to all functions to meet HQRM standards.
Style changes to meet HQRM standards.
Fixed issue using CIDR notation for LocalAddress or RemoteAddress.
See GitHub issue.
Fixed integration tests so that values being set are correctly tested.
Added integration tests for Removal of Firewall rule.
Added NetworkingDsc.Common module to contain shared networking functions.
MSFT_xDNSServerAddress:
Separated Localization strings into strings file.
MSFT_xDefaultGatewayAddress:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xDhcpClient:
Separated Localization strings into strings file.
Fix parameter descriptions in MOF file.
Style changes to meet HQRM standards.
MSFT_xDnsClientGlobalSetting:
Renamed Localization strings file to be standard naming format.
Moved ParameterList into a new file (MSFT_xDnsClientGlobalSetting.data.psd1).
Style changes to meet HQRM standards.
Removed New-TerminatingError function because never called.
Converted to remove Invoke-Expression.
MSFT_xDnsConnectionSuffix:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xHostsFile:
Renamed Localization strings file to be standard naming format.
Style changes to meet HQRM standards.
Refactored for performance
Code now reads 38k lines in > 1 second vs 4
Now ignores inline comments
Added more integration tests
MSFT_xIPAddress:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xNetAdapterBinding:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xNetAdapterRDMA:
Renamed Localization strings file to be standard naming format.
Style changes to meet HQRM standards.
MSFT_xNetBIOS:
Renamed Localization strings file to be standard naming format.
Style changes to meet HQRM standards.
MSFT_xNetConnectionProfile:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xNetworkTeam:
Style changes to meet HQRM standards.
MSFT_xNetworkTeamInterface:
Updated integration tests to remove Invoke-Expression.
Style changes to meet HQRM standards.
MSFT_xRoute:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xFirewall:
Converted to remove Invoke-Expression.
xPSDesiredStateConfiguration 5.2.0.0
xWindowsProcess
Minor updates to integration tests because one of the tests was flaky.
xRegistry:
Added support for forward slashes in registry key names. This resolves issue 285.
xSqlServer 5.0.0.0
Improvements how tests are initiated in AppVeyor
Removed previous workaround (issue 201) from unit tests.
Changes in appveyor.yml so that SQL modules are removed before common test is run.
Now the deploy step are no longer failing when merging code into Dev. Neither is the deploy step failing if a contributor had AppVeyor connected to the fork of xSQLServer and pushing code to the fork.
Changes to README.md
Changed the contributing section to help new contributors.
Added links for each resource so it is easier to navigate to the parameter list for each resource.
Moved the list of resources in alphabetical order.
Moved each resource parameter list into alphabetical order.
Removed old text mentioning System Center.
Now the correct product name is written in the installation section, and a typo was also fixed.
Fixed a typo in the Requirements section.
Added link to Examples folder in the Examples section.
Change the layout of the README.md to closer match the one of PSDscResources
Added more detailed text explaining what operating systemes WMF5.0 can be installed on.
Verified all resource schema files with the README.md and fixed some errors (descriptions was not verified).
Added security requirements section for resource xSQLServerEndpoint and xSQLAOGroupEnsure.
Changes to xSQLServerSetup
The resource no longer uses Win32_Product WMI class when evaluating if SQL Server Management Studio is installed. See article kb974524 for more information.
Now it uses CIM cmdlets to get information from WMI classes.
Resolved all of the PSScriptAnalyzer warnings that was triggered in the common tests.
Improvement for service accounts to enable support for Managed Service Accounts as well as other nt authority accounts
Changes to the helper function Copy-ItemWithRoboCopy
Robocopy is now started using Start-Process and the error handling has been improved.
Robocopy now removes files at the destination path if they no longer exists at the source.
Robocopy copies using unbuffered I/O when available (recommended for large files).
Added a more descriptive text for the parameter SourceCredential to further explain how the parameter work.
BREAKING CHANGE: Removed parameter SourceFolder.
BREAKING CHANGE: Removed default value “$PSScriptRoot….” from parameter SourcePath.
Old code, that no longer filled any function, has been replaced.
Function ResolvePath has been replaced with [Environment]::ExpandEnvironmentVariables($SourcePath) so that environment variables still can be used in Source Path.
Function NetUse has been replaced with New-SmbMapping and Remove-SmbMapping.
Renamed function GetSQLVersion to Get-SqlMajorVersion.
BREAKING CHANGE: Renamed parameter PID to ProductKey to avoid collision with automatic variable $PID
Changes to xSQLServerScript
All credential parameters now also has the type [System.Management.Automation.Credential()] to better work with PowerShell 4.0.
It is now possible to configure two instances on the same node, with the same script.
Added to the description text for the parameter Credential describing how to authenticate using Windows Authentication.
Added examples to show how to authenticate using either SQL or Windows authentication.
A recent issue showed that there is a known problem running this resource using PowerShell 4.0. For more information, see issue #273
Changes to xSQLServerFirewall
BREAKING CHANGE: Removed parameter SourceFolder.
BREAKING CHANGE: Removed default value “$PSScriptRoot….” from parameter SourcePath.
Old code, that no longer filled any function, has been replaced.
Function ResolvePath has been replaced with [Environment]::ExpandEnvironmentVariables($SourcePath) so that environment variables still can be used in Source Path.
Adding new optional parameter SourceCredential that can be used to authenticate against SourcePath.
Solved PSSA rules errors in the code.
Get-TargetResource no longer return $true when no products was installed.
Changes to the unit test for resource
xSQLServerSetup
Added test coverage for helper function Copy-ItemWithRoboCopy
Changes to xSQLServerLogin
Removed ShouldProcess statements
Added the ability to enforce password policies on SQL logins
Added common test (xSQLServerCommon.Tests) for xSQLServer module
Now all markdown files will be style checked when tests are running in AppVeyor after sending in a pull request.
Now all Examples will be tested by compiling to a .mof file after sending in a pull request.
Changes to xSQLServerDatabaseOwner
The example “SetDatabaseOwner” can now compile, it wrongly had a DependsOn in the example.
Changes to SQLServerRole
The examples “AddServerRole” and “RemoveServerRole” can now compile, it wrongly had a DependsOn in the example.
Changes to CONTRIBUTING.md
Added section “Tests for examples files”
Added section “Tests for style check of Markdown files”
Added section “Documentation with Markdown”
Added texts to section “Tests”
Changes to xSQLServerHelper
added functions
Get-SqlDatabaseRecoveryModel
Set-SqlDatabaseRecoveryModel
Examples
xSQLServerDatabaseRecoveryModel
1-SetDatabaseRecoveryModel.ps1
xSQLServerDatabasePermission
1-GrantDatabasePermissions.ps1
2-RevokeDatabasePermissions.ps1
3-DenyDatabasePermissions.ps1
xSQLServerFirewall
1-CreateInboundFirewallRules
2-RemoveInboundFirewallRules
Added tests for resources
xSQLServerDatabaseRecoveryModel
xSQLServerDatabasePermissions
xSQLServerFirewall
Changes to xSQLServerDatabaseRecoveryModel
BREAKING CHANGE: Renamed xSQLDatabaseRecoveryModel to xSQLServerDatabaseRecoveryModel to align with naming convention.
BREAKING CHANGE: The mandatory parameters now include SQLServer, and SQLInstanceName.
Changes to xSQLServerDatabasePermission
BREAKING CHANGE: Renamed xSQLServerDatabasePermissions to xSQLServerDatabasePermission to align wíth naming convention.
BREAKING CHANGE: The mandatory parameters now include PermissionState, SQLServer, and SQLInstanceName.
Added support for clustered installations to xSQLServerSetup
Migrated relevant code from xSQLServerFailoverClusterSetup
Removed Get-WmiObject usage
Clustered storage mapping now supports asymmetric cluster storage
Added support for multi-subnet clusters
Added localized error messages for cluster object mapping
Updated README.md to reflect new parameters
Updated description for xSQLServerFailoverClusterSetup to indicate it is deprecated.
xPDT helper module
Function GetxPDTVariable was removed since it no longer was used by any resources.
File xPDT.xml was removed since it was not used by any resources, and did not provide any value to the module.
Changes xSQLServerHelper moduled
Removed the globally defined $VerbosePreference = Continue from xSQLServerHelper.
Fixed a typo in a variable name in the function New-ListenerADObject.
Now Restart-SqlService will correctly show the services it restarts. Also fixed PSSA warnings.
xWebAdministration 1.17.0.0
Added removal of self signed certificate to the integration tests of xWebsite, fixes 276.
Added EnabledProtocols to xWebApplication.
Changed SSLFlags for xWebApplication to comma seperate multiple SSL flags, fixes 232.
How to Find Released DSC Resource Modules
To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.
Of course, you can also always use PowerShellGet (available in WMF 5.0) to find modules with DSC Resources:
# To list all modules that are part of the DSC Resource Kit Find-Module -Tag DSCResourceKit # To list all DSC resources from all sources Find-DscResource
To find a specific module, go directly to its URL on the PowerShell Gallery: http://ift.tt/1FzKWKv< module name > For example: http://ift.tt/1IxiVp1
How to Install DSC Resource Modules From the PowerShell Gallery
We recommend that you use PowerShellGet to install DSC resource modules:
Install-Module -Name < module name >
For example:
Install-Module -Name xWebAdministration
To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:
Update-Module
After installing modules, you can discover all DSC resources available to your local system with this command:
Get-DscResource
How to Find DSC Resource Modules on GitHub
All resource modules in the DSC Resource Kit are available open-source on GitHub. You can see the most recent state of a resource module by visiting its GitHub page at: http://ift.tt/1TMedwe< module name > For example, for the xCertificate module, go to: http://ift.tt/1IxiXgI.
All DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.
How to Contribute
You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones. See our contributing guide for more info on how to become a DSC Resource Kit contributor.
If you would like to help, please take a look at the list of open issues for the DscResources repository. You can also check issues for specific resource modules by going to: http://ift.tt/1TMedwe< module name >/issues For example: http://ift.tt/1JhnNnX
Your help in developing the DSC Resource Kit is invaluable to us!
Questions, comments?
If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.
Katie Keim Software Engineer PowerShell Team @katiedsc (Twitter) @kwirkykat (GitHub)
from DIYS http://ift.tt/2kuLdfe
0 notes
Text
DSC Resource Kit Release January 2017
We just released the DSC Resource Kit!
This release includes updates to 7 DSC resource modules, including 10 new DSC resources. In these past 6 weeks, 71 pull requests have been merged and 37 issues have been closed, all thanks to our amazing community!
The modules updated in this release are:
AuditPolicyDsc
xDismFeature
xExchange
xNetworking
xPSDesiredStateConfiguration
xSQLServer
xWebAdministration
For a detailed list of the resource modules and fixes in this release, see the Included in this Release section below.
xHyper-V has changes to be released, but the tests have a few issues at the moment. We will release it as soon as those issues are resolved. PSDscResources does not currently have any changes to release, but there are some changes queuing up. We will release it again soon once those changes are ready. We will update this blog post when either of these modules is released.
A new version of xActiveDirectory was also released about two weeks ago with some bug fixes for xADDomain and xADDomainController.
Our last community call for the DSC Resource Kit was last week on January 18. A recording of our updates as well as summarizing notes are available. Join us next time at 9AM PST on March 1 to ask questions and give feedback about your experience with the DSC Resource Kit. Keep an eye on the community agenda for the link to the call agenda.
We strongly encourage you to update to the newest version of all modules using the PowerShell Gallery, and don’t forget to give us your feedback in the comments below, on GitHub, or on Twitter (@PowerShell_Team)!
All resources with the ‘x’ prefix in their names are still experimental – this means that those resources are provided AS IS and are not supported through any Microsoft support program or service. If you find a problem with a resource, please file an issue on GitHub.
Included in this Release
You can see a detailed summary of all changes included in this release in the table below. For past release notes, go to the README.md or Changelog.md file on the GitHub repository page for a specific module (see the How to Find DSC Resource Modules on GitHub section below for details on finding the GitHub page for a specific module).
Module Name Version Release Notes AuditPolicyDsc 1.1.0.0
Added the AuditPolicyCsv resource.
xDismFeature 1.2.0.0
xDismFeature: Resource no longer includes the Source parameter when it is not specified
Converted appveyor.yml to install Pester from PSGallery instead of from Chocolatey.
xExchange 1.13.0.0
Fix function RemoveVersionSpecificParameters
xExchMailboxServer: Added missing parameters except these, which are marked as “This parameter is reserved for internal Microsoft use.”
xNetworking 3.2.0.0
Fixed typo in the example”s Action property from “Blocked” (which isn”t a valid
value) to “Block”
Added support for auto generating wiki, help files, markdown linting
and checking examples.
Added NetworkingDsc.ResourceHelper module based on copy from PSDscResources.
MSFT_xFirewall:
Cleaned up ParameterList table layout and moved into a new file
(MSFT_xFirewall.data.psd1).
Separated Localization strings into strings file.
Added standard help blocks to all functions to meet HQRM standards.
Added CmdletBinding attribute to all functions to meet HQRM standards.
Style changes to meet HQRM standards.
Fixed issue using CIDR notation for LocalAddress or RemoteAddress.
See GitHub issue.
Fixed integration tests so that values being set are correctly tested.
Added integration tests for Removal of Firewall rule.
Added NetworkingDsc.Common module to contain shared networking functions.
MSFT_xDNSServerAddress:
Separated Localization strings into strings file.
MSFT_xDefaultGatewayAddress:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xDhcpClient:
Separated Localization strings into strings file.
Fix parameter descriptions in MOF file.
Style changes to meet HQRM standards.
MSFT_xDnsClientGlobalSetting:
Renamed Localization strings file to be standard naming format.
Moved ParameterList into a new file (MSFT_xDnsClientGlobalSetting.data.psd1).
Style changes to meet HQRM standards.
Removed New-TerminatingError function because never called.
Converted to remove Invoke-Expression.
MSFT_xDnsConnectionSuffix:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xHostsFile:
Renamed Localization strings file to be standard naming format.
Style changes to meet HQRM standards.
Refactored for performance
Code now reads 38k lines in > 1 second vs 4
Now ignores inline comments
Added more integration tests
MSFT_xIPAddress:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xNetAdapterBinding:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xNetAdapterRDMA:
Renamed Localization strings file to be standard naming format.
Style changes to meet HQRM standards.
MSFT_xNetBIOS:
Renamed Localization strings file to be standard naming format.
Style changes to meet HQRM standards.
MSFT_xNetConnectionProfile:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xNetworkTeam:
Style changes to meet HQRM standards.
MSFT_xNetworkTeamInterface:
Updated integration tests to remove Invoke-Expression.
Style changes to meet HQRM standards.
MSFT_xRoute:
Separated Localization strings into strings file.
Style changes to meet HQRM standards.
MSFT_xFirewall:
Converted to remove Invoke-Expression.
xPSDesiredStateConfiguration 5.2.0.0
xWindowsProcess
Minor updates to integration tests because one of the tests was flaky.
xRegistry:
Added support for forward slashes in registry key names. This resolves issue 285.
xSqlServer 5.0.0.0
Improvements how tests are initiated in AppVeyor
Removed previous workaround (issue 201) from unit tests.
Changes in appveyor.yml so that SQL modules are removed before common test is run.
Now the deploy step are no longer failing when merging code into Dev. Neither is the deploy step failing if a contributor had AppVeyor connected to the fork of xSQLServer and pushing code to the fork.
Changes to README.md
Changed the contributing section to help new contributors.
Added links for each resource so it is easier to navigate to the parameter list for each resource.
Moved the list of resources in alphabetical order.
Moved each resource parameter list into alphabetical order.
Removed old text mentioning System Center.
Now the correct product name is written in the installation section, and a typo was also fixed.
Fixed a typo in the Requirements section.
Added link to Examples folder in the Examples section.
Change the layout of the README.md to closer match the one of PSDscResources
Added more detailed text explaining what operating systemes WMF5.0 can be installed on.
Verified all resource schema files with the README.md and fixed some errors (descriptions was not verified).
Added security requirements section for resource xSQLServerEndpoint and xSQLAOGroupEnsure.
Changes to xSQLServerSetup
The resource no longer uses Win32_Product WMI class when evaluating if SQL Server Management Studio is installed. See article kb974524 for more information.
Now it uses CIM cmdlets to get information from WMI classes.
Resolved all of the PSScriptAnalyzer warnings that was triggered in the common tests.
Improvement for service accounts to enable support for Managed Service Accounts as well as other nt authority accounts
Changes to the helper function Copy-ItemWithRoboCopy
Robocopy is now started using Start-Process and the error handling has been improved.
Robocopy now removes files at the destination path if they no longer exists at the source.
Robocopy copies using unbuffered I/O when available (recommended for large files).
Added a more descriptive text for the parameter SourceCredential to further explain how the parameter work.
BREAKING CHANGE: Removed parameter SourceFolder.
BREAKING CHANGE: Removed default value “$PSScriptRoot….” from parameter SourcePath.
Old code, that no longer filled any function, has been replaced.
Function ResolvePath has been replaced with [Environment]::ExpandEnvironmentVariables($SourcePath) so that environment variables still can be used in Source Path.
Function NetUse has been replaced with New-SmbMapping and Remove-SmbMapping.
Renamed function GetSQLVersion to Get-SqlMajorVersion.
BREAKING CHANGE: Renamed parameter PID to ProductKey to avoid collision with automatic variable $PID
Changes to xSQLServerScript
All credential parameters now also has the type [System.Management.Automation.Credential()] to better work with PowerShell 4.0.
It is now possible to configure two instances on the same node, with the same script.
Added to the description text for the parameter Credential describing how to authenticate using Windows Authentication.
Added examples to show how to authenticate using either SQL or Windows authentication.
A recent issue showed that there is a known problem running this resource using PowerShell 4.0. For more information, see issue #273
Changes to xSQLServerFirewall
BREAKING CHANGE: Removed parameter SourceFolder.
BREAKING CHANGE: Removed default value “$PSScriptRoot….” from parameter SourcePath.
Old code, that no longer filled any function, has been replaced.
Function ResolvePath has been replaced with [Environment]::ExpandEnvironmentVariables($SourcePath) so that environment variables still can be used in Source Path.
Adding new optional parameter SourceCredential that can be used to authenticate against SourcePath.
Solved PSSA rules errors in the code.
Get-TargetResource no longer return $true when no products was installed.
Changes to the unit test for resource
xSQLServerSetup
Added test coverage for helper function Copy-ItemWithRoboCopy
Changes to xSQLServerLogin
Removed ShouldProcess statements
Added the ability to enforce password policies on SQL logins
Added common test (xSQLServerCommon.Tests) for xSQLServer module
Now all markdown files will be style checked when tests are running in AppVeyor after sending in a pull request.
Now all Examples will be tested by compiling to a .mof file after sending in a pull request.
Changes to xSQLServerDatabaseOwner
The example “SetDatabaseOwner” can now compile, it wrongly had a DependsOn in the example.
Changes to SQLServerRole
The examples “AddServerRole” and “RemoveServerRole” can now compile, it wrongly had a DependsOn in the example.
Changes to CONTRIBUTING.md
Added section “Tests for examples files”
Added section “Tests for style check of Markdown files”
Added section “Documentation with Markdown”
Added texts to section “Tests”
Changes to xSQLServerHelper
added functions
Get-SqlDatabaseRecoveryModel
Set-SqlDatabaseRecoveryModel
Examples
xSQLServerDatabaseRecoveryModel
1-SetDatabaseRecoveryModel.ps1
xSQLServerDatabasePermission
1-GrantDatabasePermissions.ps1
2-RevokeDatabasePermissions.ps1
3-DenyDatabasePermissions.ps1
xSQLServerFirewall
1-CreateInboundFirewallRules
2-RemoveInboundFirewallRules
Added tests for resources
xSQLServerDatabaseRecoveryModel
xSQLServerDatabasePermissions
xSQLServerFirewall
Changes to xSQLServerDatabaseRecoveryModel
BREAKING CHANGE: Renamed xSQLDatabaseRecoveryModel to xSQLServerDatabaseRecoveryModel to align with naming convention.
BREAKING CHANGE: The mandatory parameters now include SQLServer, and SQLInstanceName.
Changes to xSQLServerDatabasePermission
BREAKING CHANGE: Renamed xSQLServerDatabasePermissions to xSQLServerDatabasePermission to align wíth naming convention.
BREAKING CHANGE: The mandatory parameters now include PermissionState, SQLServer, and SQLInstanceName.
Added support for clustered installations to xSQLServerSetup
Migrated relevant code from xSQLServerFailoverClusterSetup
Removed Get-WmiObject usage
Clustered storage mapping now supports asymmetric cluster storage
Added support for multi-subnet clusters
Added localized error messages for cluster object mapping
Updated README.md to reflect new parameters
Updated description for xSQLServerFailoverClusterSetup to indicate it is deprecated.
xPDT helper module
Function GetxPDTVariable was removed since it no longer was used by any resources.
File xPDT.xml was removed since it was not used by any resources, and did not provide any value to the module.
Changes xSQLServerHelper moduled
Removed the globally defined $VerbosePreference = Continue from xSQLServerHelper.
Fixed a typo in a variable name in the function New-ListenerADObject.
Now Restart-SqlService will correctly show the services it restarts. Also fixed PSSA warnings.
xWebAdministration 1.17.0.0
Added removal of self signed certificate to the integration tests of xWebsite, fixes 276.
Added EnabledProtocols to xWebApplication.
Changed SSLFlags for xWebApplication to comma seperate multiple SSL flags, fixes 232.
How to Find Released DSC Resource Modules
To see a list of all released DSC Resource Kit modules, go to the PowerShell Gallery and display all modules tagged as DSCResourceKit. You can also enter a module’s name in the search box in the upper right corner of the PowerShell Gallery to find a specific module.
Of course, you can also always use PowerShellGet (available in WMF 5.0) to find modules with DSC Resources:
# To list all modules that are part of the DSC Resource Kit Find-Module -Tag DSCResourceKit # To list all DSC resources from all sources Find-DscResource
To find a specific module, go directly to its URL on the PowerShell Gallery: http://ift.tt/1FzKWKv< module name > For example: http://ift.tt/1IxiVp1
How to Install DSC Resource Modules From the PowerShell Gallery
We recommend that you use PowerShellGet to install DSC resource modules:
Install-Module -Name < module name >
For example:
Install-Module -Name xWebAdministration
To update all previously installed modules at once, open an elevated PowerShell prompt and use this command:
Update-Module
After installing modules, you can discover all DSC resources available to your local system with this command:
Get-DscResource
How to Find DSC Resource Modules on GitHub
All resource modules in the DSC Resource Kit are available open-source on GitHub. You can see the most recent state of a resource module by visiting its GitHub page at: http://ift.tt/1TMedwe< module name > For example, for the xCertificate module, go to: http://ift.tt/1IxiXgI.
All DSC modules are also listed as submodules of the DscResources repository in the xDscResources folder.
How to Contribute
You are more than welcome to contribute to the development of the DSC Resource Kit! There are several different ways you can help. You can create new DSC resources or modules, add test automation, improve documentation, fix existing issues, or open new ones. See our contributing guide for more info on how to become a DSC Resource Kit contributor.
If you would like to help, please take a look at the list of open issues for the DscResources repository. You can also check issues for specific resource modules by going to: http://ift.tt/1TMedwe< module name >/issues For example: http://ift.tt/1JhnNnX
Your help in developing the DSC Resource Kit is invaluable to us!
Questions, comments?
If you’re looking into using PowerShell DSC, have questions or issues with a current resource, or would like a new resource, let us know in the comments below, on Twitter (@PowerShell_Team), or by creating an issue on GitHub.
Katie Keim Software Engineer PowerShell Team @katiedsc (Twitter) @kwirkykat (GitHub)
from DIYS http://ift.tt/2kuLdfe
0 notes
Text
Original Post from Security Affairs Author: Pierluigi Paganini
Researchers at Guardicore Labs reported that the Smominru botnet is rapidly spreading and now is already infecting over 90,000 machines each month around worldwide.
In February 2018, researchers from Proofpoint discovered a huge botnet dubbed ‘Smominru’ that was using the EternalBlue exploit to infect Windows computers and recruit them in Monerocryptocurrency mining activities. According to the researchers, the Smominru botnet has been active at least since May 2017 and at the time of its discovery infected more than 526,000 Windows computers.
According to a new report published by the researchers at Guardicore Labs, the Smominru, is rapidly spreading and now is already infecting over 90,000 machines each month around worldwide.
The report published by Guardicore Labs researchers analyzes the attack chain and the nature of the victims.
Experts discovered that many machines recruited in the botnet were reinfected even after removing the Smominru, a circumstance that suggests that these systems remain unpatched since first infection.
“During August, the Smominru botnet infected 90,000 machines around the world, with an infection rate of 4,700 machines per day. Countries with several thousands of infected machines include China, Taiwan, Russia, Brazil and the US.” reads the report published by the experts.
Most of the infected systems are Windows 7 and Windows Server 2008, representing 85 percent of all infections, in China, Taiwan, Russia, Brazil and the US.
In just one month, the worm infected more than 4,900 networks, some of them had dozens of internal machines infected. The largest network belongs to a healthcare provider in Italy, experts observed a total of 65 infected hosts.
Once compromised the system, a first-stage Powershell script named blueps.txt is downloaded onto the machine. This script performs the following actions:
It downloads and executes three binary files;
It creates a new administrative user named admin$ on the system;
It downloads additional scripts to perform malicious actions.
Once gained access to the targeted systems, Smominru installs a Trojan module and a cryptocurrency miner and attempt to infect other machines inside the target network.
The botnet main purpose continues to be crypto-mining but recently experts observed that operators added a data harvesting module and Remote Access Trojan (RAT) to their botnet’scryptocurrency mining code.
The latest variant of Smominru downloads and runs at least 20 distinct malicious scripts and binary payloads, including a worm downloader and an MBR rootkit.
The storage infrastructure is widely distributed, experts found more than 20 servers, each of them serves a few files and each file references additional 2-3 servers.
Operators stored many of the files on more than one hosting server, to improve the resilience of attack infrastructure to takedowns and its flexibility.
Most of the machines are located in the US, with some hosted by ISPs in Malaysia and Bulgaria.
“The attackers create many backdoors on the machine in different phases of the attack. These include newly-created users, scheduled tasks, WMI objects and services set to run at boot time.”continues the report.”The MS-SQL attack flow includes a unique persistence method; the attackers use the obscure task scheduling engine inside MS-SQL to run jobs at different time intervals, e.g. upon reboot, every 30 minutes, etc. “
Guardicore Labs experts managed to gain access to one of the attackers’ servers and analyzed its content to gather information on the nature of the victims.
“The attackers’ logs describe each infected host; they include its external and internal IP addresses, the operating system it runs and even the load on the system’s CPU(s). Furthermore, the attackers attempt to collect the running processes and steal credentials using Mimikatz,” the researchers say. continues the report.
Unlike previous variants, the new Smominru bot also removes infections from compromised systems and blocking TCP ports (SMB, RPC) to prevent infections by other threat actors.
Further data, including Indicators of Compromise, are reported in the analysis published by the experts.
window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = "3121199";
try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag("762221962", "300x250", "762221962"); }); } catch (error) {}
Pierluigi Paganini
(SecurityAffairs – APT, hacking)
The post Smominru Botnet continues to rapidly spread worldwide appeared first on Security Affairs.
#gallery-0-6 { margin: auto; } #gallery-0-6 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-6 img { border: 2px solid #cfcfcf; } #gallery-0-6 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */
Go to Source Author: Pierluigi Paganini Smominru Botnet continues to rapidly spread worldwide Original Post from Security Affairs Author: Pierluigi Paganini Researchers at Guardicore Labs reported that the Smominru…
0 notes
Text
A List of SCCM Log Files
All logs open with cmtrace (C:\Program Files\Microsoft Configuration Manager\tools). Client Log Files CAS – Content Access Service. Maintains the local package cache. Ccmexec.log – Records activities of the client and the SMS Agent Host service. CertificateMaintenance.log – Maintains certificates for Active Directory directory service and management points. ClientIDManagerStartup.log – Creates and maintains the client GUID. ClientLocation.log – Site assignment tasks. ContentTransferManager.log – Schedules the Background Intelligent Transfer Service (BITS) or the Server Message Block (SMB) to download or to access SMS packages. DataTransferService.log – Records all BITS communication for policy or package access. Execmgr.log – Records advertisements that run. FileBITS.log – Records all SMB package access tasks. Fsinvprovider.log (renamed to FileSystemFile.log in all SMS 2003 Service Packs) – Windows Management Instrumentation (WMI) provider for software inventory and file collection. InventoryAgent.log – Creates discovery data records (DDRs) and hardware and software inventory records. LocationServices.log – Finds management points and distribution points. Mifprovider.log – The WMI provider for .MIF files. Mtrmgr.log – Monitors all software metering processes. PolicyAgent.log – Requests policies by using the Data Transfer service. PolicyAgentProvider.log – Records policy changes. PolicyEvaluator.log – Records new policy settings. Remctrl.log – Logs when the remote control component (WUSER32) starts. Scheduler.log – Records schedule tasks for all client operations. Smscliui.log – Records usage of the Systems Management tool in Control Panel. StatusAgent.log – Logs status messages that are created by the client components. SWMTRReportGen.log – Generates a usage data report that is collected by the metering agent. (This data is logged in Mtrmgr.log.) Server Log Files Ccm.log – Client Configuration Manager tasks. Cidm.log – Records changes to the client settings by the Client Install Data Manager (CIDM). Colleval.log – Logs when collections are created, changed, and deleted by the Collection Evaluator. Compsumm.log – Records Component Status Summarizer tasks. Cscnfsvc.log – Records Courier Sender confirmation service tasks. Dataldr.log – Processes Management Information Format (MIF) files and hardware inventory in the Configuration Manager 2007 database. Ddm.log – Saves DDR information to the Configuration Manager 2007 database by the Discovery Data Manager. Despool.log – Records incoming site-to-site communication transfers. Distmgr.log – Records package creation, compression, delta replication, and information updates. Hman.log – Records site configuration changes, and publishes site information in Active Directory Domain Services. Inboxast.log – Records files that are moved from the management point to the corresponding SMS\INBOXES folder. Inboxmgr.log – Records file maintenance. Invproc.log – Records the processing of delta MIF files for the Dataloader component from client inventory files. Mpcontrol.log – Records the registration of the management point with WINS. Records the availability of the management point every 10 minutes. Mpfdm.log – Management point component that moves client files to the corresponding SMS\INBOXES folder. MPMSI.log – Management point .msi installation log. MPSetup.log – Records the management point installation wrapper process. Ntsvrdis.log – Configuration Manager 2007 server discovery. Offermgr.log – Records advertisement updates. Offersum.log – Records summarization of advertisement status messages. Policypv.log – Records updates to the client policies to reflect changes to client settings or advertisements. Replmgr.log – Records the replication of files between the site server components and the Scheduler component. Rsetup.log – Reporting point setup log. Sched.log – Records site-to-site job and package replication. Sender.log – Records files that are sent to other child and parent sites. Sinvproc.log – Records client software inventory data processing to the site database in Microsoft SQL Server. Sitecomp.log – Records maintenance of the installed site components. Sitectrl.log – Records site setting changes to the Sitectrl.ct0 file. Sitestat.log – Records the monitoring process of all site systems. Smsdbmon.log – Records database changes. Smsexec.log – Records processing of all site server component threads. Smsprov.log – Records WMI provider access to the site database. SMSReportingInstall.log – Records the Reporting Point installation. This component starts the installation tasks and processes configuration changes. SMSSHVSetup.log – Records the success or failure (with failure reason) of installing the System Health Validator point. Srvacct.log – Records the maintenance of accounts when the site uses standard security. Statmgr.log – Writes all status messages to the database. Swmproc.log – Processes metering files and maintains settings. Admin Console Log Files RepairWizard.log – Records errors, warnings, and information about the process of running the Repair Wizard. ResourceExplorer.log – Records errors, warnings, and information about running the Resource Explorer. SMSAdminUI.log – Records the local Configuration Manager 2007 console tasks when you connect to Configuration Manager 2007 sites. Management Point Log Files MP_Ddr.log – Records the conversion of XML.ddr records from clients, and copies them to the site server. MP_GetAuth.log – Records the status of the site management points. MP_GetPolicy.log – Records policy information. MP_Hinv.log – Converts XML hardware inventory records from clients and copies the files to the site server. MP_Location.log – Records location manager tasks. MP_Policy.log – Records policy communication. MP_Relay.log – Copies files that are collected from the client. MP_Retry.log – Records the hardware inventory retry processes. MP_Sinv.log – Converts XML hardware inventory records from clients and copies them to the site server. MP_Status.log – Converts XML.svf status message files from clients and copies them to the site server. Mobile Device Management Log Files DmClientHealth.log – Records the GUIDs of all the mobile device clients that are communicating with the Device Management Point. DmClientRegistration.log – Records registration requests from and responses to the mobile device client in Native mode. DmpDatastore.log – Records all the site database connections and queries made by the Device Management Point. DmpDiscovery.log – Records all the discovery data from the mobile device clients on the Device Management Point. DmpFileCollection.log – Records mobile device file collection data from mobile device clients on the Device Management Point. DmpHardware.log – Records hardware inventory data from mobile device clients on the Device Management Point. DmpIsapi.log – Records mobile device communication data from device clients on the Device Management Point. dmpMSI.log – Records the MSI data for Device Management Point setup. DMPSetup.log – Records the mobile device management setup process. DmpSoftware.log – Records mobile device software distribution data from mobile device clients on the Device Management Point. DmpStatus.log – Records mobile device status messages data from mobile device clients on the Device Management Point. FspIsapi.log – Records Fallback Status Point communication data from mobile device clients and client computers on the Fallback Status Point. Mobile Device Client Log Files DmCertEnroll.log – Records certificate enrollment data on mobile device clients. DMCertResp.htm (in \temp) – Records HTML response from the certificate server when the mobile device Enroller program requests a client authentication certificate on mobile device clients. DmClientSetup.log – Records client setup data on mobile device clients. DmClientXfer.log – Records client transfer data for Windows Mobile Device Center and ActiveSync deployments. DmCommonInstaller.log – Records client transfer file installation for setting up mobile device client transfer files on client computers. DmInstaller.log – Records whether DMInstaller correctly calls DmClientSetup and whether DmClientSetup exits with success or failure on mobile device clients. DmInvExtension.log – Records Inventory Extension file installation for setting up Inventory Extension files on client computers. DmSvc.log – Records mobile device management service data on mobile device clients. Operating System Deployment Log Files CCMSetup.log – Provides information about client-based operating system actions. CreateTSMedia.log – Provides information about task sequence media when it is created. This log is generated on the computer running the Configuration Manager 2007 administrator console. DriverCatalog.log – Provides information about device drivers that have been imported into the driver catalog. MP_ClientIDManager.log – Provides information about the Configuration Manager 2007 management point when it responds to Configuration Manager 2007 client ID requests from boot media or PXE. This log is generated on the Configuration Manager 2007 management point. MP_DriverManager.log – Provides information about the Configuration Manager 2007 management point when it responds to a request from the Auto Apply Driver task sequence action. This log is generated on the Configuration Manager 2007 management point. MP_Location.log – Provides information about the Configuration Manager 2007 management point when it responds to request state store or release state store requests from the state migration point. This log is generated on the Configuration Manager 2007 management point. Pxecontrol.log – Provides information about the PXE Control Manager. PXEMsi.log – Provides information about the PXE service point and is generated when the PXE service point site server has been created. PXESetup.log – Provides information about the PXE service point and is generated when the PXE service point site server has been created. Setupact.log Setupapi.log Setuperr.log Provide information about Windows Sysprep and setup logs. SmpIsapi.log – Provides information about the state migration point Configuration Manager 2007 client request responses. Smpmgr.log – Provides information about the results of state migration point health checks and configuration changes. SmpMSI.log – Provides information about the state migration point and is generated when the state migration point site server has been created. Smsprov.log – Provides information about the SMS provider. Smspxe.log – Provides information about the Configuration Manager 2007 PXE service point. SMSSMPSetup.log – Provides information about the state migration point and is generated when the state migration point site server has been created. Smsts.log – General location for all operating system deployment and task sequence log events. TaskSequenceProvider.log – Provides information about task sequences when they are imported, exported, or edited. USMT Log loadstate.log – Provides information about the User State Migration Tool (USMT) regarding the restore of user state data. USMT Log scanstate.log – Provides information about the USMT regarding the capture of user state data. Network Access Protection Log Files Ccmcca.log – Logs the processing of compliance evaluation based on Configuration Manager NAP policy processing and contains the processing of remediation for each software update required for compliance. CIAgent.log – Tracks the process of remediation and compliance. However, the software updates log file, *Updateshandler.log – provides more informative details on installing the software updates required for compliance. locationservices.log – Used by other Configuration Manager features (for example, information about the client’s assigned site) but also contains information specific to Network Access Protection when the client is in remediation. It records the names of the required remediation servers (management point, software update point, and distribution points that host content required for compliance), which are also sent in the client statement of health. SDMAgent.log – Shared with the Configuration Manager feature desired configuration management and contains the tracking process of remediation and compliance. However, the software updates log file, Updateshandler.log, provides more informative details about installing the software updates required for compliance. SMSSha.log – The main log file for the Configuration Manager Network Access Protection client and contains a merged statement of health information from the two Configuration Manager components: location services (LS) and the configuration compliance agent (CCA). This log file also contains information about the interactions between the Configuration Manager System Health Agent and the operating system NAP agent, and also between the Configuration Manager System Health Agent and both the configuration compliance agent and the location services. It provides information about whether the NAP agent successfully initialized, the statement of health data, and the statement of health response. System Health Validator Point Log Files Ccmperf.log -Contains information about the initialization of the System Health Validator point performance counters. SmsSHV.log – The main log file for the System Health Validator point; logs the basic operations of the System Health Validator service, such as the initialization progress. SmsSHVADCacheClient.log – Contains information about retrieving Configuration Manager health state references from Active Directory Domain Services. SmsSHVCacheStore.log – Contains information about the cache store used to hold the Configuration Manager NAP health state references retrieved from Active Directory Domain Services, such as reading from the store and purging entries from the local cache store file. The cache store is not configurable. SmsSHVRegistrySettings.log – Records any dynamic changes to the System Health Validator component configuration while the service is running. SmsSHVQuarValidator.log – Records client statement of health information and processing operations. To obtain full information, change the registry key LogLevel from 1 to 0 in the following location:HKLM\SOFTWARE\Microsoft\SMSSHV\Logging\@GLOBAL Desired Configuration Management Log Files ciagent.log – Provides information about downloading, storing, and accessing assigned configuration baselines. dcmagent.log – Provides high-level information about the evaluation of assigned configuration baselines and desired configuration management processes. discovery.log – Provides detailed information about the Service Modeling Language (SML) processes. sdmagent.log – Provides information about downloading, storing, and accessing configuration item content. sdmdiscagent.log – Provides high-level information about the evaluation process for the objects and settings configured in the referenced configuration items. Wake On LAN Log Files Wolmgr.log – Contains information about wake-up procedures such as when to wake up advertisements or deployments that are configured for Wake On LAN. WolCmgr.log – Contains information about which clients need to be sent wake-up packets, the number of wake-up packets sent, and the number of wake-up packets retried. Software Updates Site Server Log Files ciamgr.log – Provides information about the addition, deletion, and modification of software update configuration items. distmgr.log – Provides information about the replication of software update deployment packages. objreplmgr.log – Provides information about the replication of software updates notification files from a parent to child sites. PatchDownloader.log – Provides information about the process for downloading software updates from the update source specified in the software updates metadata to the download destination on the site server. replmgr.log – Provides information about the process for replicating files between sites. smsdbmon.log – Provides information about when software update configuration items are inserted, updated, or deleted from the site server database and creates notification files for software updates components. SUPSetup – Provides information about the software update point installation. When the software update point installation completes, Installation was successful is written to this log file. WCM.log – Provides information about the software update point configuration and connecting to the Windows Server Update Services (WSUS) server for subscribed update categories, classifications, and languages. WSUSCtrl.log – Provides information about the configuration, database connectivity, and health of the WSUS server for the site. wsyncmgr.log -Provides information about the software updates synchronization process. WSUS Server Log Files Change.log – Provides information about the WSUS server database information that has changed. SoftwareDistribution.log – Provides information about the software updates that are synchronized from the configured update source to the WSUS server database. Software Updates Client Computer Log Files CAS.log – Provides information about the process of downloading software updates to the local cache and cache management. CIAgent.log – Provides information about processing configuration items, including software updates. LocationServices.log – Provides information about the location of the WSUS server when a scan is initiated on the client. PatchDownloader.log – Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates. PolicyAgent.log – Provides information about the process for downloading, compiling, and deleting policies on client computers. PolicyEvaluator – Provides information about the process for evaluating policies on client computers, including policies from software updates. RebootCoordinator.log – Provides information about the process for coordinating system restarts on client computers after software update installations. ScanAgent.log – Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on. ScanWrapper – Provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients. SdmAgent.log – Provides information about the process for verifying and decompressing packages that contain configuration item information for software updates. ServiceWindowManager.log – Provides information about the process for evaluating configured maintenance windows. smscliUI.log – Provides information about the Configuration Manager Control Panel user interactions, such as initiating a Software Updates Scan Cycle from the Configuration Manager Properties dialog box, opening the Program Download Monitor, and so on. SmsWusHandler – Provides information about the scan process for the Inventory Tool for Microsoft Updates on SMS 2003 client computers. StateMessage.log – Provides information about when software updates state messages are created and sent to the management point. UpdatesDeployment.log – Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface. UpdatesHandler.log – Provides information about software update compliance scanning and about the download and installation of software updates on the client. UpdatesStore.log – Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle. WUAHandler.log – Provides information about when the Windows Update Agent on the client searches for software updates. WUSSyncXML.log – Provides information about the Inventory Tool for the Microsoft Updates synchronization process. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates. Windows Update Agent Log File WindowsUpdate.log – Provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components. (adsbygoogle = window.adsbygoogle || ).push({}); Click to Post
0 notes