Microsoft Docs - Latest Articles

Test-CsPstnOutboundCall (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-cspstnoutboundcall The Test-CsPstnOutboundCall cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts you will need to supply the logon names and passwords for each user. Test-CsPstnOutboundCall can also be used in server platform mode. In that case you only need to specify the SIP address of a user, and Skype for Business Server will use certificates to authenticate that user. When you run the Test-CsPstnOutboundCall cmdlet, the cmdlet first attempts to log the test user on to Skype for Business Server. If the logon succeeds, the cmdlet will then attempt to make a phone call across the PSTN gateway. This phone call will be placed using the dial plan, voice policy, and other policies and settings assigned to the test account. When the call is answered, the cmdlet sends dual-tone multi-frequency (DTMF) codes across the network in order to verify media connectivity. When conducting its test, the Test-CsPstnOutboundCall cmdlet will make an actual phone call: the target phone will ring and must be answered for the test to succeed. This call must also be manually ended by the administrator.
Published Date : Monday, September 25, 2017

Test-CsRegistration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csregistration The Test-CsRegistration cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts you will need to supply the logon names and passwords for each user. The Test-CsRegistration cmdlet enables you to verify that users in your organization can log on to Skype for Business Server. In order to perform this check, the Test-CsRegistration cmdlet requires a single test account. If you have set up test users for the pool where the test is to be conducted, then you do not need to specify an account; instead, the Test-CsRegistration cmdlet will automatically use the first test account that was assigned to the pool. (For details, see the New-CsHealthMonitoringConfiguration cmdlet help topic.) Alternatively, you can conduct the test using an account that has not been assigned to the pool. This allows you run tests even if you have not configured test users. It also allows you to test the ability of a specific user to log on to Skype for Business Server. (If you choose to use this approach, you will need to provide the user name and password for the account being tested.) When you run the Test-CsRegistration cmdlet, the cmdlet attempts to sign the test user on to Skype for Business Server and then, if successful, disconnects that test user from the system. All of this happens without any user interaction, and without affecting any actual users. For example, suppose the test account sip:kenmyer corresponds to a real user with a real Skype for Business Server account. In that case, the test will be conducted without any disruption to the real Ken Myer. When the Ken Myer test account logs off from the system, Ken Myer the person will remain logged on. Adding the Verbose parameter enables you to get a detailed account of all the actions taken by the Test-CsRegistration cmdlet in order to complete its test.
Published Date : Monday, September 25, 2017

Test-CsPstnPeerToPeerCall (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-cspstnpeertopeercall The Test-CsPstnPeerToPeerCall cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts you will need to supply the logon names and passwords for each user. The Test-CsPstnPeerToPeerCall cmdlet can also be used in server platform mode. In that case you only need to specify the SIP address of the users and Skype for Business Server will use certificates to authenticate those users. When you call Test-CsPstnPeerToPeerCall the cmdlet will first attempt to log the two test users on to Skype for Business Server. Assuming that the logons succeed, the cmdlet will then have user 1 attempt to call user 2 over the PSTN gateway; the Test-CsPstnPeerToPeerCall cmdlet will make this call using the dial plan, voice policy, and other policy and configurations settings assigned to the test user. If the test goes as planned, the cmdlet will verify that user 2 was able to answer the call, and then log both test accounts off of the system. The Test-CsPstnPeerToPeerCall cmdlet makes an actual phone call, one that verifies that a connection can be made and that also transmits dual-tone multifrequency (DTMF) codes across the network to determine whether media can be sent over the connection. However, the call is answered by the cmdlet itself, and no manual termination of the call is necessary. (That is, no one needs to answer and then hang up the phone that was called.)
Published Date : Monday, September 25, 2017

Test-CsWatcherNodeConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-cswatchernodeconfiguration If you are using Microsoft System Center Operations Manager to monitor Skype for Business Server then you have the option of setting up "watcher nodes": computers that periodically, and automatically, run synthetic transactions in order to verify that Skype for Business Server is working as expected. Watcher nodes are assigned to pools, and are managed using the CsWatcherNodeConfiguration cmdlets. Note that you do not need to install watcher nodes if you are using System Center Operations Manager. You can still monitor your system without using watcher nodes; the only difference is that any synthetic transactions you want to run will need to be invoked manually rather than automatically invoked by Operations Manager. The Test-CsWatcherNodeConfiguration cmdlet provides a way for you to verify that a watcher node has been correctly configured and is assigned to a valid Skype for Business Server pool. Note that the Test-CsWatcherNodeConfiguration cmdlet must be run on the watcher node itself; the cmdlet cannot be run against remote computers. Skype for Business Server Control Panel: The functions carried out by the Test-CsWatcherNodeConfiguration cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

Test-CsP2PVideoInteropServerSipTrunkAV (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csp2pvideointeropserversiptrunkav The Test-CsP2PVideoInteropServerSipTrunkAV cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as System Center Operations Manager. Synthetic transactions can be run against a pool, or specific users. Administrators will generally use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. The test users are pre-configured for use with synthetic transactions. With test users configured for a pool, administrators can run a synthetic transaction against that pool without having to provide specific users and credentials. Administrators can also run a synthetic transaction using actual Skype for Business user accounts. For example, if one user is reporting audio or video issues, you could use the Test-CsP2PVideoInteropServerSipTrunkAV cmdlet to test that user's connection to the VIS pool and that connection's support of audio and video streams. The cmdlet accepts one actual user per run. If you test VIS using actual user accounts you need to supply the logon names and passwords for each user via a credential object created by the Get-Credential cmdlet. See Example 1 for more information. Cmdlet pre-requisites The following are pre-requisites for running the Test-CsP2PVideoInteropServerSipTrunkAV cmdlet. <WatcherNode Fqdn="watchernode.contoso.com" Port="5555" CertThumbPrint="80182fdbb901ef061b57bf65e5a0907ff876e02e" /> </VISPools> Configure the VIS Pools to trust the watcher node by using the New-CsVideoInteropServerSyntheticTransactionConfiguration or Set-CsVideoInteropServerSyntheticTransactionConfiguration cmdlets. Please see the Related Topics section for more information When you call Test-CsCsP2PVideoInteropServerSipTrunkAV the cmdlet will first attempt to log the synthetic or actual user on to Skype for Business Server. Assuming that the logon succeeds, the cmdlet will simulate a video gateway and attempt to call the test user over the Video Trunk setup with the VIS Pool specified in the configuration file. The Test-CsP2PVideoInteropServerSipTrunkAV cmdlet verifies the connection by making an audio-video call to the test user via the target VIS pool. That call also transmits audio-video streams across the network to determine whether media can be sent over the connection. The call is answered by the cmdlet itself, and no manual termination of the call is necessary (no one needs to answer or hang up the call.) To return a list of all the Role-Based Access Control (RBAC) roles a cmdlet has been assigned to (including any custom RBAC roles you have created), run the following command from the Windows PowerShell prompt. Get-CsAdminRole | Where-Object {$_.Cmdlets -Match "\<DesiredCmdletName\>"}
Published Date : Monday, September 25, 2017

Test-CsIM (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csim The Test-CsIM cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator can run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) to try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts you will need to supply credentials for each user. The Test-CsIM cmdlet starts off by trying to log a pair of test users on to Skype for Business Server. Assuming the two logons are successful, the cmdlet then initiates an instant messaging (IM) session between the two test users. (User 1 invites User 2 to an IM session, and User 2 accepts the invitation.) After verifying that messages can be exchanged between the two users, the Test-CsIM cmdlet then ends the IM session and logs both users off of the system.
Published Date : Monday, September 25, 2017

Test-CsPresence (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-cspresence The Test-CsPresence cmdlet is an example of a Skype for Business Server synthetic transaction. Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. Typically, these are test accounts and not accounts belonging to actual users. With these user accounts configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator can run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts, you will need to supply the logon names and passwords for each user. The Test-CsPresence cmdlet is used to determine whether a pair of test users can log on to Skype for Business Server and then exchange presence information. To do this, the cmdlet first logs the two users on to the system. If both logons succeed, the first test user then asks to receive presence information from the second user. The second user publishes this information, and the Test-CsPresence cmdlet verifies that the information was successfully transmitted to the first user. After the exchange of presence information, the two test users are then logged off from Skype for Business Server.
Published Date : Monday, September 25, 2017

Test-CsP2PAV (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csp2pav The Test-CsP2PAV cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts you will need to supply the logon names and passwords for each user. The Test-CsP2PAV cmdlet is used to determine whether two test users are able to participate in a peer-to-peer audio/video (A/V) conversation. To test this scenario, the cmdlet starts off by logging the two users on to Lync Server. Assuming that the two logons succeed, the first user then invites the second user to join an A/V call. The second user accepts the call, the connection between the two users is tested, and then the call is ended and the test users are logged off from the system. The Test-CsP2PAV cmdlet does not actually conduct an A/V call; multimedia information is not exchanged between the test users. Instead, the cmdlet simply verifies that the appropriate connections can be made and that the two users are capable of conducting such a call.
Published Date : Monday, September 25, 2017

Test-CsDialInConferencing (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csdialinconferencing The Test-CsDialInConferencing cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts, you will need to supply the logon names and passwords for each user. The Test-CsDialInConferencing cmdlet works by attempting to log a test user onto the system. (If you are using test users, the Test-CsDialInConferencing cmdlet will use the first test account configured for that pool.) If logon succeeds, the cmdlet will then use the user's credentials and permissions to try the available dial-in conferencing access numbers. The success or failure of each dial-in attempt will be noted, then the test user will be logged off from Skype for Business Server. The Test-CsDialInConferencing cmdlet only verifies that the appropriate connections can be made. The cmdlet does not actually make any phone calls or create any dial-in conferences that other users can join.
Published Date : Monday, September 25, 2017

Test-CsGroupIM (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csgroupim The Test-CsGroupIM cmdlet is an example of a Skype for Business Server synthetic transaction. Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts), and then try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts, you will need to supply credentials for each user. The Test-CsGroupIM cmdlet enables you to verify that users in your organization can conduct conferences. The Test-CsGroupIM cmdlet requires two user accounts in order to conduct its tests. If you have set up test users for the pool where the test is to be conducted, then you do not need to specify these accounts; instead, the Test-CsGroupIM cmdlet will automatically use the test accounts assigned to pool. (For details, see the New-CsHealthMonitoringConfiguration cmdlet help topic.) Alternatively, you can conduct the test using accounts other than the ones assigned to the Registrar. This allows you run tests even if you have not configured test users for the pool. It also allows you to test the ability of two specific users to conduct a conference. If you choose to use this approach, you will need to provide the user name and password for both users. When you run the Test-CsGroupIM cmdlet, the cmdlet attempts to sign both test users on to Skype for Business Server. If successful, the Test-CsGroupIM cmdlet creates a new conference using the first test user, then invites the second user to join the conference. After an exchange of messages, both users are then disconnected from the system. All of this happens without any user interaction, and without affecting any actual users. For example, suppose the test account sip:kenmyer corresponds to a real user with a real Skype for Business Server account. In that case, the test will be conducted without any disruption to the real Ken Myer. For example, even when the Ken Myer test account logs off from the system, Ken Myer the person will remain logged on. Likewise, the real Ken Myer will not receive an invitation to join the conference. That invitation will be sent to, and accepted by, the test account. Adding the Verbose parameter enables you to get a detailed account of all the actions taken by the Test-CsGroupIM cmdlet in order to complete its test.
Published Date : Monday, September 25, 2017

Test-CsComputer (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-cscomputer The Test-CsComputer cmdlet is an example of a Skype for Business Server "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be run automatically by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). The Test-CsComputer cmdlet, which can be run only on the local computer, verifies the status of all the Skype for Business Server services on that computer. The cmdlet also checks to see if the appropriate firewall ports have been opened on the computer, and determines whether or not the Active Directory groups created when you installed Skype for Business Server have been added to the corresponding local groups. For example, the Test-CsComputer cmdlet will verify that the Active Directory group RTCUniversalUserAdmins has been added to the local Administrators group.
Published Date : Monday, September 25, 2017

Test-CsAVConference (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csavconference The Test-CsAVConference cmdlet is an example of a "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction by using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using those two user accounts (as opposed to a pair of test accounts), and then try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts, you will need to supply the logon names and passwords for each user. The Test-CsAVConference cmdlet checks to see if two test users are able to conduct an A/V conference. When the cmdlet runs, the two users are logged on to the system. After they are successfully logged on, the first user creates an A/V conference, and then waits for the second user to join that conference. After a brief exchange of data, the conference is deleted and the two tests users are logged off. The Test-CsAVConference cmdlet does not actually conduct an A/V conference between the two test users. Instead, the cmdlet verifies that the two users can make the connections necessary to carry out an A/V conference.
Published Date : Monday, September 25, 2017

Test-CsAddressBookService (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csaddressbookservice The Test-CsAddressBookService cmdlet is an example of a "synthetic transaction". Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction by using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using those two user accounts (as opposed to a pair of test accounts), and then try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts, you will need to supply the logon names and passwords for each user. The Test-CsAddressBookService cmdlet provides a way for you to verify that a user can connect to the Address Book Download Web service. When run, the Test-CsAddressBookService cmdlet connects to the Address Book Download Web service on the specified pool and requests the location of the Address Book files. If the Address Book Download Web service supplies that location, the test is considered successful. If the request is denied, then the test is considered a failure. You can test the Address Book Download Web service in two different ways: by testing the service itself or by testing the associated Web service.
Published Date : Monday, September 25, 2017

Test-CsAddressBookWebQuery (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-csaddressbookwebquery The Test-CsAddressBookWebQuery cmdlet is an example of a "synthetic transaction". Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test users for each of their Registrar pools. These test users are a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) With test users configured for a pool, administrators can run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Alternatively, administrators can run a synthetic transaction by using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using those two user accounts (as opposed to a pair of test accounts), and then try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts, you will need to supply the logon names and passwords for each user. The Test-CsAddressBookWebQuery cmdlet provides a way for administrators to verify that users can use the Address Book Web Query service to search for a specific contact. When run, the Test-CsAddressBookWebQuery cmdlet will first connect to the Web Ticket service in order to be authenticated. If authentication is successful, the cmdlet will then connect to the Address Book Web Query service and search for the specified contact. If that contact is found, the cmdlet will attempt to return that information to the local computer. The test will be marked a success only if all of those steps can be completed.
Published Date : Monday, September 25, 2017

Test-CsCertificateConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/test-cscertificateconfiguration The Test-CsCertificateConfiguration cmdlet is an example of a "synthetic transaction." Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). The Test-CsCertificateConfiguration cmdlet returns information about the certificates being used by Skype for Business Server. The Test-CsCertificateConfiguration cmdlet is primarily intended for use by the Certificate wizard. It is recommended that administrators use the Get-CsCertificate cmdlet to retrieve certificate information.
Published Date : Monday, September 25, 2017

Set-CsWatcherNodeConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/set-cswatchernodeconfiguration If you are using Microsoft System Center Operations Manager to monitor Skype for Business Server then you have the option of setting up "watcher nodes": computers that periodically and automatically, run synthetic transactions in order to verify that Skype for Business Server is working as expected. Watcher nodes are assigned to pools, and are managed using the CsWatcherNodeConfiguration cmdlets. Note that you do not need to install watcher nodes if you are using System Center Operations Manager. You can still monitor your system without using watcher nodes; the only difference is that any synthetic transactions you want to run will need to be invoked manually rather than automatically invoked by Operations Manager. Skype for Business Server Control Panel: The functions carried out by the Set-CsWatcherNodeConfiguration cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

Set-CsVideoInteropServerSyntheticTransactionConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/set-csvideointeropserversynthetictransactionconfiguration To return a list of all the Role-Based Access Control (RBAC) roles a cmdlet has been assigned to (including any custom RBAC roles you have created), run the following command from the Windows PowerShell prompt. Get-CsAdminRole | Where-Object {$_.Cmdlets -Match "\<DesiredCmdletName\>"}
Published Date : Monday, September 25, 2017

Set-CsTestUserCredential (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/set-cstestusercredential If you are using System Center Operations Manager in conjunction with Skype for Business Server, you have the option of configuring "watcher node" computers. Watcher nodes are computers that periodically (and automatically) run synthetic transactions. Synthetic transactions are cmdlets that test various features of Skype for Business Server; for example, there are synthetic transactions that verify that users can register with Skype for Business Server; that users can exchange instant messages and presence information using Skype for Business Server; that users can conduct data collaboration and application sharing conferences and that users can make phone calls across the public switched telephone network. As noted, these synthetic transactions run periodically and if they fail, issue alerts notifying administrators that the system might be experiencing difficulties. Many synthetic transactions require test users; for example, you cannot test the ability of two users to exchange instant messages unless you have a pair of user accounts and you attempt to exchange instant messages using those accounts. When you configure a watcher node you must assign at least two test users to that node. These test users can be any valid Active Directory user accounts that have been enabled for Skype for Business Server and have been registered as test accounts. Accounts are registered as test accounts by using the Set-CsTestUserCredential cmdlet. If you later decide not to use an account as a test account you can unregister the by using the Remove-CsTestUserCredential cmdlet. This cmdlet simply prevents the account from being used as a watcher node test account; it does not delete, disable or otherwise modify the account. Skype for Business Server Control Panel: The functions carried out by the Set-CsTestUserCredential cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

Set-CsHealthMonitoringConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/set-cshealthmonitoringconfiguration Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions can be conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test accounts for each of their Registrar pools. These test accounts are a pair of user accounts that have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) When test accounts are configured for a pool, administrators can run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Instead, the synthetic transaction will automatically use the preconfigured test accounts when performing its checks. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator can run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts). If you decide to conduct a synthetic transaction using actual user accounts that you will have to supply the credentials for each user. After you have configured health monitoring configuration settings, you can modify those settings at any time by using the Set-CsHealthMonitoringConfiguration cmdlet. This cmdlet provides a way for you to change either (or both) of the test accounts configured for use with a pool.
Published Date : Monday, September 25, 2017

Remove-CsWatcherNodeConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/remove-cswatchernodeconfiguration If you are using Microsoft System Center Operations Manager to monitor Skype for Business Server then you have the option of setting up "watcher nodes": computers that periodically and automatically, run synthetic transactions in order to verify that Skype for Business Server is working as expected. Watcher nodes are assigned to pools and are managed using the CsWatcherNodeConfiguration cmdlets. Note that you do not need to install watcher nodes if you are using System Center Operations Manager. You can still monitor your system without using watcher nodes; the only difference is that any synthetic transactions you want to run will need to be invoked manually rather than automatically invoked by Operations Manager. If you later decide to decommission a watcher node you can do so by using the Remove-CsWatcherNodeConfiguration cmdlet. Alternatively, you can temporarily disable (and then later re-enable) a watcher node by using the Set-CsWatcherNodeConfiguration cmdlet. Skype for Business Server Control Panel: The functions carried out by the Remove-CsWatcherNodeConfiguration cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

Remove-CsTestUserCredential (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/remove-cstestusercredential If you are using System Center Operations Manager in conjunction with Skype for Business Server, you have the option of configuring "watcher node" computers. Watcher nodes are computers that periodically (and automatically) run synthetic transactions. Synthetic transactions are cmdlets that test various features of Skype for Business Server; for example, there are synthetic transactions that verify that users can register with Skype for Business Server; that users can exchange instant messages and presence information using Skype for Business Server; that users can conduct data collaboration and application sharing conferences; and that users can make phone calls across the public switched telephone network. As noted, these synthetic transactions run periodically and, if they fail, issue alerts notifying administrators that the system might be experiencing difficulties. Many synthetic transactions require test users; for example, you cannot test the ability of two users to exchange instant messages unless you have a pair of user accounts and you attempt to exchange instant messages using those accounts. When you configure a watcher node you must assign at least two test users to that node. These test users can be any valid Active Directory user accounts that have been enabled for Skype for Business Server and have been registered as test accounts. Accounts are registered as test accounts by using the Set-CsTestUserCredential cmdlet. If you later decide not to use an account as a test account you can unregister the by using the Remove-CsTestUserCredential cmdlet. This cmdlet simply prevents the account from being used as a watcher node test account; it does not delete, disable, or otherwise modify the account. Skype for Business Server Control Panel: The functions carried out by the Remove-CsTestUserCredential cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

Remove-CsHealthMonitoringConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/remove-cshealthmonitoringconfiguration Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted manually by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions can be conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test accounts for each of their Registrar pools. These test accounts are a pair of user accounts that have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) When these test accounts are configured for a pool, administrators can run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Instead, the synthetic transaction will automatically use the preconfigured test accounts when performing its checks. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator can run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts). If you decide to conduct a synthetic transaction using actual user accounts you will have to supply the credentials for each user. The Remove-CsHealthMonitoringConfiguration cmdlet provides a way for you to remove any of the health monitoring configuration settings that have been configured for use in your organization.
Published Date : Monday, September 25, 2017

New-CsWatcherNodeConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/new-cswatchernodeconfiguration If you are using Microsoft System Center Operations Manager to monitor Skype for Business Server then you have the option of setting up "watcher nodes": computers that periodically and automatically, run synthetic transactions in order to verify that Skype for Business Server is working as expected. Watcher nodes are assigned to pools, and are managed using the CsWatcherNodeConfiguration cmdlets. Note that you do not need to install watcher nodes if you are using System Center Operations Manager. You can still monitor your system without using watcher nodes; the only difference is that any synthetic transactions you want to run will need to be invoked manually rather than automatically invoked by Operations Manager. Skype for Business Server Control Panel: The functions carried out by the New-CsWatcherNodeConfiguration cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

New-CsVideoInteropServerSyntheticTransactionConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/new-csvideointeropserversynthetictransactionconfiguration To return a list of all the Role-Based Access Control (RBAC) roles a cmdlet has been assigned to (including any custom RBAC roles you have created), run the following command from the Windows PowerShell prompt. Get-CsAdminRole | Where-Object {$_.Cmdlets -Match "\<DesiredCmdletName\>"}
Published Date : Monday, September 25, 2017

New-CsExtendedTest (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/new-csextendedtest If you are using Microsoft System Center Operations Manager to monitor Skype for Business Server then you have the option of setting up "watcher nodes": computers that periodically, and automatically, run synthetic transactions in order to verify that Skype for Business Server is working as expected. Watcher nodes are assigned to pools, and are managed using the CsWatcherNodeConfiguration cmdlets. Note that you do not need to install watcher nodes if you are using System Center Operations Manager. You can still monitor your system without using watcher nodes; the only difference is that any synthetic transactions you want to run will need to be invoked manually rather than automatically invoked by Operations Manager. When you configure a watcher node, you have the option of adding a PSTN or an Audio Conferencing Provider test as an "extended test"; these extended tests can be used instead of or in addition to the standard set of tests run by a watcher node computer. Extended tests must be created using the New-CsExtendedTest cmdlet and then added to the appropriate watcher node. Skype for Business Server Control Panel: The functions carried out by the New-CsExtendedTest cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

New-CsHealthMonitoringConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/new-cshealthmonitoringconfiguration Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted "manually" by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions can be conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test accounts for each of their Registrar pools. These test accounts are a pair of user accounts that have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) When these test accounts are configured for a pool, administrators can run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Instead, the synthetic transaction will automatically use the preconfigured test accounts when performing its checks. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator can run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts). If you decide to conduct a synthetic transaction using actual user accounts you will have to supply the credentials for each user. The New-CsHealthMonitoringConfiguration cmdlet provides a way for you to create a new health monitoring configuration settings for a Registrar or Director pool. When creating a new collection of health monitoring configuration settings, you must specify the fully qualified domain name (FQDN) of the pool, as well as the SIP addresses of the two accounts that will serve as the pool test accounts. (However, you do not need to provide the passwords for those test accounts.) Note that each pool can host, at most, a single collection of health monitoring configuration settings. If you try to create a new collection for the pool atl-cs-001.litwareinc.com and this pool has already been assigned a Registrar, then your command will fail. When you run the New-CsHealthMonitoringConfiguration cmdlet you might receive a warning if you have pools that have not been assigned test users; this might include Director pools as well as Office Communications Server pools. These warnings can be ignored. If you prefer, you can assign test users homed on other pools to your Director pools; that would enable you to run the Test-CsRegistration cmdlet against the Director. However, test users cannot be assigned to Office Communications Server pools.
Published Date : Monday, September 25, 2017

Get-CsWatcherNodeConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/get-cswatchernodeconfiguration If you are using Microsoft System Center Operations Manager to monitor Skype for Business Server then you have the option of setting up "watcher nodes": computers that periodically, and automatically, run synthetic transactions in order to verify that Skype for Business Server is working as expected. Watcher nodes are assigned to pools, and are managed using the CsWatcherNodeConfiguration cmdlets. Note that you do not need to install watcher nodes if you are using System Center Operations Manager. You can still monitor your system without using watcher nodes; the only difference is that any synthetic transactions you want to run will need to be invoked manually rather than automatically invoked by Operations Manager. The Get-CsWatcherNodeConfiguration cmdlet returns information about all the watcher nodes that have been configured for use in your organization. Skype for Business Server Control Panel: The functions carried out by the Get-CsWatcherNodeConfiguration cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

Get-CsTestUserCredential (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/get-cstestusercredential If you are using System Center Operations Manager in conjunction with Skype for Business Server, you have the option of configuring "watcher node" computers. Watcher nodes are computers that periodically (and automatically) run synthetic transactions. Synthetic transactions are cmdlets that test various features of Skype for Business Server; for example, there are synthetic transactions that verify that users can register with Skype for Business Server; that users can exchange instant messages and presence information using Skype for Business Server; that users can conduct data collaboration and application sharing conferences; and that users can make phone calls across the public switched telephone network. As noted, these synthetic transactions run periodically and, if they fail, issue alerts notifying administrators that the system might be experiencing difficulties. Many synthetic transactions require test users; for example, you cannot test the ability of two users to exchange instant messages unless you have a pair of user accounts and you attempt to exchange instant messages using those accounts. When you configure a watcher node you must assign at least two test users to that node. These test users can be any valid Active Directory user accounts that have been enabled for Skype for Business Server and have been registered as test accounts. Accounts are registered as test accounts by using the Set-CsTestUserCredential cmdlet. If you later decide not to use an account as a test account you can unregister the by using the Remove-CsTestUserCredential cmdlet. This cmdlet simply prevents the account from being used as a watcher node test account; it does not delete, disable, or otherwise modify the account. The functions carried out by the Get-CsTestUserCredential cmdlet are not available in the Skype for Business Server Control Panel.
Published Date : Monday, September 25, 2017

Get-CsHealthMonitoringConfiguration (SkypeForBusiness)

https://docs.microsoft.com/en-us/powershell/module/skype/get-cshealthmonitoringconfiguration Synthetic transactions are used in Skype for Business Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the public switched telephone network (PSTN). These tests can be conducted "manually" by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager (formerly Microsoft Operations Manager). Synthetic transactions can be conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up test accounts for each of their Registrar or Director pools. These test accounts are a pair of user accounts that have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts that belong to actual users.) When test accounts have been configured for a pool, administrators can run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test. Instead, the synthetic transaction will automatically use the preconfigured test accounts when performing its checks. Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator can run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts). If you decide to conduct a synthetic transaction using actual user accounts you will have to supply the credentials for each user. The Get-CsHealthMonitoringConfiguration cmdlet provides a way for you to retrieve information about the health monitoring configuration settings currently in use in your organization.
Published Date : Monday, September 25, 2017

Test-WebServicesConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-webservicesconnectivity The Test-WebServicesConnectivity cmdlet tests Exchange Web Services connectivity by connecting to a specified Exchange Web Services virtual directory, to any Exchange Web Services virtual directories on a specified Exchange server, or to any Exchange Web Services virtual directories that are available in the local Active Directory site. The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 The test results are displayed on-screen. The cmdlet returns the following information. Source: Source server. ServiceEndpoint: Destination server. Scenario: The operations that are tested. Values are Autodiscover: SOAP Provider and EWS: GetFolder (full mode) or EWS: ConvertID (light mode). Result: The values returned are typically Success or *FAILURE*. Latency(MS): The time required to complete the test in milliseconds You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding > <filename> to the command. For example: Test-WebServicesConnectivity -ClientAccessServer MBX01 | ConvertTo-Html | Set-Content -Path "C:\My Documents\EWS Test.html" You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-UMConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-umconnectivity Two diagnostic tests are designed to test the operation of the Mailbox server software (mode 1) and the operation of the whole system that includes the connected telephony components (mode 2). The Test-UMConnectivity cmdlet can be used to test the operation of a Mailbox server and related connected telephony equipment. When you run this cmdlet and include the UMIPGateway parameter, the Mailbox server tests the full end-to-end operation of the Unified Messaging system. This test includes the telephony components connected to the Mailbox server, such as IP gateways, Private Branch eXchanges (PBXs) and cabling. If the UMIPGateway parameter isn't specified, the Mailbox server tests only the operation of the Unified Messaging components that are installed and configured on the server. When you run this cmdlet in an on-premises Unified Messaging deployment, you need to create a UM IP gateway object for the computer or server that the cmdlet is testing. When you create the UM IP gateway object, you must configure it with a fully qualified domain name (FQDN) and that FQDN must match the name of the computer running this cmdlet. After this task is complete, the cmdlet will have tested the operation of the Mailbox server and related telephony components. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-OutlookConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-outlookconnectivity Running the Test-OutlookConnectivity cmdlet validates an Outlook connection defined by the provided parameters. The command is able to validate a single mailbox. The Test-OutlookConnectivity cmdlet runs the same process as the monitoring probes. The Microsoft Exchange Health Manager (MSExchangeHM) service must be running and have created the Outlook probes on the machine that will be tested. You need to select one of the Outlook probe identities to run the test. Use the Get-MonitoringItemIdentity cmdlet to see what probes are active. This example lists the probes running in the backend services on a Mailbox server: Get-MonitoringItemIdentity -Server MailboxServer1 -Identity outlook.protocol | ?{$_.Name -like '*probe'}. This example lists the probes running in the client access services on a Mailbox server: Get-MonitoringItemIdentity -Server MailboxServer1 -Identity outlook | ?{$_.Name -like '*probe'}. For more information on probes and the monitoring framework, see Managed Availability, Managed Availability and Server Health, and Customizing Managed Availability. By default, the cmdlet uses the test monitoring account attached to the specified probe. You may enter a different mailbox instead via the MailboxId parameter. The options and results follow. MailboxId and Credential are not specified: Generic connectivity test against a test mailbox using the system's test credentials. MailboxId is specified, Credential is not: Connectivity test to the specific mailbox using the system's test credentials. MailboxId and Credential are both specified: You get a connectivity test to the specific mailbox, and also a test that the credentials provided are valid for that mailbox You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-ExchangeSearch (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-exchangesearch The Test-ExchangeSearch cmdlet creates a hidden message and an attachment in the specified mailbox that's visible only to Exchange Search. The command waits for the message to be indexed and then searches for the content. It reports success or failure depending on whether the message is found after the interval set in the IndexingTimeoutInSeconds parameter has elapsed. You can use the Verbose switch to get detailed information about each step performed by the cmdlet as part of the test. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-SmtpConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-smtpconnectivity When you run the Test-SmtpConnectivity cmdlet against a Mailbox server, the cmdlet attempts to establish an SMTP connection to all bindings of all Receive connectors hosted on that server. For each attempt, the cmdlet returns the following information: Server: The name of the server that hosts the Receive connector. ReceiveConnector: The name of the Receive connector to which the SMTP connection was attempted. Binding: The binding that was configured on the Receive connector. EndPoint: The actual IP address and port to which the SMTP connection was attempted. StatusCode: The result of the connection attempt. This can be one of the following values: Success, Unable to connect, Transient error, Permanent error, External error. Details: The actual response received from the server being tested. If the connection attempt isn't successful, this field contains an error string. The Test-SmtpConnectivity results are displayed on-screen. You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding "> <filename>" to the command. For example: You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-OwaConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-owaconnectivity The Test-OwaConnectivity cmdlet tests the connectivity of all Exchange Outlook Web App virtual directories on a Client Access server or tests connectivity of a single Exchange Outlook Web App URL. To test all Exchange Outlook Web App virtual directories on a Client Access server, there must be a test Active Directory account. There must also be a test mailbox in each Active Directory site that hosts mailboxes that can be accessed through the virtual directories being tested. If the test environment wasn't created during the Mailbox server setup, you are prompted to run the script that creates the test mailboxes and test users when you run the Test-OwaConnectivity cmdlet. If the server hosting the test mailbox isn't available, the Test-OwaConnectivity cmdlet returns an error that might not clearly identify the problem. To avoid this, check that the server that hosts the test mailbox is running and that the mailbox is available before you run the Test-OwaConnectivity cmdlet. You can use the Test-MapiConnectivity cmdlet to do this. If you run the Test-OwaConnectivity cmdlet on a Client Access server without using either the ClientAccessServer parameter or the URL parameter, the cmdlet tests the server on which you run the cmdlet. To test a specific Client Access server, use the ClientAccessServer parameter. To test a single URL, run the Test-OwaConnectivity cmdlet with the URL parameter and credentials for an existing Exchange mailbox. If the URL is behind a load balancer, you can't predict which Client Access server the command will test. Because credentials are required as part of the parameters when you use the URL parameter, you can use any account to run the Test-OwaConnectivity cmdlet when you use the URL parameter. If the command encounters a virtual directory that doesn't require Secure Sockets Layer (SSL), the command skips that directory unless the AllowUnsecureAccess parameter is used. If the AllowUnsecureAccess parameter is used, communications between servers are sent in clear text for purposes of the test. The Test-OwaConnectivity cmdlet can be run as a one-time interactive task or as a scheduled task under Microsoft System Center Operations Manager 2007 control. To run the Test-OwaConnectivity cmdlet as a System Center Operations Manager 2007 task, the Client Access test mailbox must be available on the Mailbox servers that the cmdlet tests against. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-EdgeSynchronization (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-edgesynchronization The Test-EdgeSynchronization cmdlet is a diagnostic cmdlet that provides a report of the synchronization status of subscribed Edge Transport servers. You can use the VerifyRecipient parameter with this cmdlet to verify that a single recipient has been synchronized to the Active Directory Lightweight Directory Services (AD LDS) instance. The Edge Subscription process establishes one-way replication of recipient and configuration information from Active Directory to AD LDS. This cmdlet compares the data stored in Active Directory and the data stored in AD LDS. Any inconsistencies in data are reported in the results output by this cmdlet. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-ServiceHealth (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-servicehealth This cmdlet isn't supported on Exchange 2013 Client Access servers (the cmdlet will return unexpected output). You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-PopConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-popconnectivity The Test-PopConnectivity cmdlet tests POP3 connectivity by connecting to a specified mailbox, a specified Exchange server, or all Exchange servers that are available in the local Active Directory site. The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 The test results are displayed on-screen. The cmdlet returns the following information. CasServer: The Exchange server that the client connected to. LocalSite: The name of the local Active Directory site. Scenario: The operations that are tested. Test POP3 Connectivity connects to the server using the POP3 protocol, searches for the test message, and deletes the test message. Result: The values returned are typically Success, Skipped or Failure. Latency(MS): The time required to complete the test in milliseconds. Error: Any error messages that were encountered. You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding > <filename> to the command. For example: Test-PopConnectivity -ClientAccessServer MBX01 | ConvertTo-Html | Set-Content -Path "C:\My Documents\POP Test.html" You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-PowerShellConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-powershellconnectivity The Test-PowerShellConnectivity cmdlet tests Exchange remote PowerShell connectivity by connecting to a specified remote PowerShell virtual directory, to any remote PowerShell virtual directories on a specified Exchange server, or to any remote PowerShell virtual directories that are available in the local Active Directory site. The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 The test results are displayed on-screen. The cmdlet returns the following information. CasServer: The Exchange server that the client connected to. LocalSite: The name of the local Active Directory site. Scenario: The operations that are tested. Values are: Logon User. Result: The values returned are typically Success, Skipped or Failure. Latency(MS): The time required to complete the test in milliseconds. Error: Any error messages that were encountered. You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding > <filename> to the command. For example: Test-PowerShellConnectivity -ClientAccessServer MBX01 | ConvertTo-Html | Set-Content -Path "C:\My Documents\PowerShell Test.html" You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-ImapConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-imapconnectivity The Test-ImapConnectivity cmdlet tests IMAP4 connectivity by connecting to the specified mailbox, the specified Exchange server, or all Exchange servers that are available in the local Active Directory site. The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 The test results are displayed on-screen. The cmdlet returns the following information. CasServer: The Exchange server that the client connected to. LocalSite: The name of the local Active Directory site. Scenario: The operations that are tested. Test IMAP4 Connectivity connects to the server using the IMAP4 protocol, searches for the test message and deletes it along with any messages that are older than 24 hours. Result: The values returned are typically Success, Skipped or Failure. Latency(MS): The time required to complete the test in milliseconds. Error: Any error messages that were encountered. You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding > <filename> to the command. For example: Test-IMAPConnectivity -ClientAccessServer MBX01 | ConvertTo-Html | Set-Content -Path "C:\My Documents\IMAP Test.html" You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet. Important Note: In Exchange 2013 or later, when you run this command to test a single mailbox on an Exchange server that isn't hosting the active mailbox database copy for the mailbox, you might see the following error message: Unable to create MailboxSession object to access the mailbox [user]. Detailed error information: [Microsoft.Exchange.Data.Storage.WrongServerException]: The user and the mailbox are in different Active Directory sites. Inner error [Microsoft.Mapi.MapiExceptionMailboxInTransit]: MapiExceptionMailboxInTransit: Detected site violation (hr=0x0, ec=1292) When you receive this error, run the command again on the server that's hosting the active mailbox database copy to verify that IMAP works for the mailbox.
Published Date : Monday, September 25, 2017

Test-ReplicationHealth (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-replicationhealth The Test-ReplicationHealth cmdlet is designed for the proactive monitoring of continuous replication and the continuous replication pipeline, the availability of Active Manager and the health and status of the underlying cluster service, quorum and network components. The Test-ReplicationHealth cmdlet can be run locally or remotely against any Mailbox server in a DAG. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-Mailflow (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-mailflow The Test-Mailflow cmdlet tests mail submission, transport, and delivery. The cmdlet verifies that each Mailbox server can successfully send itself a message. You can also use this cmdlet to verify that the system mailbox on one Mailbox server can successfully send a message to the system mailbox on another Mailbox server. A system mailbox is required on all servers that are involved in the test. The test messages are available in the target user or system mailbox. The message subject is Test-Mailflow <GUID>, and the message body contains the text This is a Test-Mailflow probe message. The Test-Mailflow results are displayed on-screen. The interesting values in the results are: TestMailflowResult: The values returned are typically Success or *FAILURE*. MessageLatencyTime: The time required to complete the test (deliver the test message). The value uses the syntax hh:mm:ss.ffff where hh = hours, mm = minutes, ss = seconds and ffff = fractions of a second. You can write the Test-Mailflow results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding "> <filename>" to the command. For example: You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-MAPIConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-mapiconnectivity The Test-MapiConnectivity cmdlet verifies server functionality. This cmdlet logs on to the mailbox that you specify (or to the SystemMailbox if you don't specify the Identity parameter) and retrieves a list of items in the Inbox. Logging on to the mailbox tests two critical protocols used when a client connects to a Mailbox server: MAPI and LDAP. During authentication, the Test-MapiConnectivity cmdlet indirectly verifies that the MAPI server, Exchange store, and Directory Service Access (DSAccess) are working. The cmdlet logs on to the mailbox that you specify using the credentials of the account with which you're logged on to the local computer. After a successful authentication, the Test-MapiConnectivity cmdlet accesses the mailbox to verify that the database is working. If a successful connection to a mailbox is made, the cmdlet also determines the time that the logon attempt occurred. There are three distinct parameters that you can use with the command: Database, Identity and Server: The Database parameter takes a database identity and tests the ability to log on to the system mailbox on the specified database. The Identity parameter takes a mailbox identity and tests the ability to log on to a specific mailbox. The Server parameter takes a server identity and tests the ability to log on to each system mailbox on the specified server. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-AssistantHealth (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-assistanthealth The Mailbox Assistants service runs on all servers that have the Mailbox server role installed. This service is responsible for scheduling and dispatching several assistants that ensure mailboxes function correctly. By default, when you run this cmdlet, it returns the RunspaceId, events, and performance counters in a table format. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-MRSHealth (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-mrshealth The Microsoft Exchange Mailbox Replication service runs on Mailbox servers. This command ensures that the Mailbox Replication service is running and that it responds to a remote procedure call (RPC) ping check. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-FederationTrust (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-federationtrust The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 You can run the Test-FederationTrust cmdlet from the Exchange Management Shell, or a monitoring system can run the test periodically. The Test-FederationTrust cmdlet runs the following series of tests to ensure that federation is working as expected: A connection to the Microsoft Federation Gateway is established. This test ensures that communication between the local Exchange server and the Microsoft Federation Gateway is working correctly. Certificates are checked to ensure they're valid and can be used with the Microsoft Federation Gateway. A security token is requested from the Microsoft Federation Gateway. This test ensures that a token can be properly retrieved and used. You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-EcpConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-ecpconnectivity The Test-EcpConnectivity cmdlet tests EAC connectivity by connecting to a specified EAC virtual directory, to any EAC virtual directories on a specified Exchange server, or to any EAC virtual directories that are available in the local Active Directory site. The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 The test results are displayed on-screen. The cmdlet returns the following information. CasServer: The Exchange server that the client connected to. LocalSite: The name of the local Active Directory site. Scenario: The operations that are tested. Values are: Logon and Sign in. Result: The values returned are typically Success, Skipped or Failure. Latency(MS): The time required to complete the test in milliseconds. Error: Any error messages that were encountered. You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding > <filename> to the command. For example: Test-EcpConnectivity -ClientAccessServer MBX01 | ConvertTo-Html | Set-Content -Path "C:\My Documents\EAC Test.html" You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-CalendarConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-calendarconnectivity The Test-CalendarConnectivity cmdlet tests anonymous calendar sharing by connecting to a specified Outlook on the web virtual directory, to any Outlook on the web virtual directories on a specified Exchange server, or to any Outlook on the web virtual directories that are available in the local Active Directory site. The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 If the server hosting the test mailbox isn't available, the command returns an error that might not clearly identify the problem. To avoid this, use the Test-MapiConnectivity cmdlet to verify that the server that hosts the test mailbox is running and that the mailbox is available before you run this command. The test results are displayed on-screen. The cmdlet returns the following information. CasServer: The Exchange server that the client connected to. LocalSite: The name of the local Active Directory site. Scenario: The operations that are tested. Values are: Logon, CalendarICS and CalendarHTML. Result: The values returned are typically Success, Skipped or Failure. Latency(MS): The time required to complete the test in milliseconds. Error: Any error messages that were encountered. You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding > <filename> to the command. For example: Test-CalendarConnectivity -ClientAccessServer MBX01 | ConvertTo-Html | Set-Content -Path "C:\My Documents\Calendar Test.html" You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Test-ActiveSyncConnectivity (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/test-activesyncconnectivity The Test-ActiveSyncConnectivity cmdlet tests Exchange ActiveSync connectivity by connecting to a specified Exchange ActiveSync virtual directory, to any Exchange ActiveSync virtual directories on a specified Exchange server, or to any Exchange ActiveSync virtual directories that are available in the local Active Directory site. The first time you use this cmdlet, you might be required to create a test user. To create a test user, run the following command: & $env:ExchangeInstallPath\Scripts\New-TestCasConnectivityUser.ps1 The test results are displayed on-screen. The cmdlet returns the following information. CasServer: The Exchange server that the client connected to. LocalSite: The name of the local Active Directory site. Scenario: The operations that are tested. Values are: Options, FolderSync, First Sync, GetItemEstimate, Sync Data, Ping, and Sync Test Item. Result: The values returned are typically Success, Skipped, or Failure. Latency(MS): The time required to complete the test in milliseconds. Error: Any error messages that were encountered. You can write the results to a file by piping the output to ConvertTo-Html or ConvertTo-Csv and adding > <filename> to the command. For example: Test-ActiveSyncConnectivity -ClientAccessServer MBX01 | ConvertTo-Html | Set-Content -Path "C:\My Documents\EAS Test.html" You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

New-AvailabilityReportOutage (ExchangePowerShell)

https://docs.microsoft.com/en-us/powershell/module/exchange/new-availabilityreportoutage You need to be assigned permissions before you can run this cmdlet. Although this topic lists all parameters for the cmdlet, you may not have access to some parameters if they're not included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see Find the permissions required to run any Exchange cmdlet.
Published Date : Monday, September 25, 2017

Plan for software updates - Configuration Manager

https://docs.microsoft.com/en-us/mem/configmgr/sum/plan-design/plan-for-software-updates A plan for the software update point infrastructure is essential before you use software updates in a Configuration Manager production environment.
Published Date : Tuesday, August 11, 2020

Migrating from Windows PowerShell 5.1 to PowerShell 7 - PowerShell

https://docs.microsoft.com/en-us/powershell/scripting/install/migrating-from-windows-powershell-51-to-powershell-7 Update from PowerShell 5.1 to PowerShell 7 for your Windows platforms.
Published Date : Wednesday, March 25, 2020

Product Compatibility Status - PowerShell

https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/wmf/whats-new/compatibility Compatible Systems that are running the following server applications can run Windows Management Framework 5.1: Microsoft SharePoint Server 2013 Skype for Business Server 2015 Microsoft Lync Server 2013 System Center 2012 Configuration Manager Note Skype for Business Server 2015 compatibility with WMF
Published Date : Monday, June 12, 2017

What's New in Windows PowerShell 5.0 - PowerShell

https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/whats-new/what-s-new-in-windows-powershell-50 Windows PE is a minimal operating system that starts a computer that has no operating system and prepares it for Windows installation. ... Updatable Help System You can now download updated help files for the cmdlets in your modules.
Published Date : Monday, June 5, 2017

Configure servers for the Rights Management connector - AIP

https://docs.microsoft.com/en-us/azure/information-protection/configure-servers-rms-connector Information to help you configure your on-premises servers that will use the Azure Rights Management (RMS) connector. These procedures cover step 5 from Deploying the Azure Rights Management connector.
Published Date : Monday, March 9, 2020

How to Configure Operations Manager to Communicate with SQL Server

https://docs.microsoft.com/en-us/system-center/scom/manage-sqlserver-communication This article describes how to reconfigure Operations Manager if you change the SQL Server configuration or SQL Server instance hosting its databases.
Published Date : Wednesday, February 19, 2020

Best practices to secure and manage workloads migrated to Azure - Cloud Adoption Framework

https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/azure-best-practices/migrate-best-practices-security-management Use the Cloud Adoption Framework for Azure to learn best practices for operating, managing, and securing your migrated workloads.
Published Date : Wednesday, July 1, 2020

Microsoft troubleshooting documentation

https://docs.microsoft.com/en-us/troubleshoot/ Find the documentation you need to troubleshoot issues and apply workarounds for the following commercial products from Microsoft.
Published Date : Wednesday, September 16, 2020

Error 80040217 when ConfigMgr clients load policies - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/client-load-policy-error-80040217 Fixes an issue where System Center Configuration Manager 2007 clients fail to load policies if the site has no network access account defined.
Published Date : Thursday, August 20, 2020

Unexpected reboot after removing computers from a collection - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/unexpected-reboot-after-removing-computers-from-collection Describes a by-design behavior in which removing computers from a collection in System Center Configuration Manager 2007 may cause an unexpected reboot.
Published Date : Thursday, August 20, 2020

Troubleshoot Advanced Client push installation issues - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/troubleshoot-advanced-client-push-installation-issues Describes how to troubleshoot Advanced Client push installation issues in Systems Management Server 2003 and System Center Configuration Manager 2007.
Published Date : Thursday, August 20, 2020

The Advanced Client no longer works - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/advanced-client-not-work Describes a problem that occurs if a Group Policy Object is configured to set the startup mode of the SMS Agent Host service to Automatic.
Published Date : Thursday, August 20, 2020

Some clients are assigned to the wrong site code - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/some-clients-assigned-wrong-site-code Fixes an issue where some clients may be assigned to the incorrect site code in System Center Configuration Manager 2007.
Published Date : Thursday, August 20, 2020

ConfigMgr 2007 backups fail with Win32 Error = 145 - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/backups-fail-with-vss-provider-issue Fixes an issue in which System Center Configuration Manager 2007 backups fail if the VSS provider is in use by another process.
Published Date : Tuesday, August 18, 2020

ConfigMgr 2007 setup fails with incorrect WebDAV settings - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/setup-fails-with-incorrect-webdav-settings Fixes an issue in which System Center Configuration Manager 2007 setup on Windows Server 2008 fails because of incorrect WebDAV settings.
Published Date : Tuesday, August 18, 2020

OSD and task sequences fail after a restoration - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/osd-task-sequences-fail Provides a solution to an issue in which OSD and task sequences no longer function after restoring System Center Configuration Manager 2007 from a backup.
Published Date : Tuesday, August 18, 2020

Site Component Manager logs error status messages - Configuration Manager

https://docs.microsoft.com/en-us/troubleshoot/previous-versions/configmgr/site-component-manager-log-status-messages Describes how to grant permissions to Systems Management Server 2003 or Configuration Manager 2007 to create or change the System Management container in Active Directory.
Published Date : Thursday, August 20, 2020

ManagementGroup.Version Property (Microsoft.Azure.Management.OperationalInsights.Models) - Azure for .NET Developers

https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.management.operationalinsights.models.managementgroup.version Gets or sets the version of System Center that is managing the management group.
Published Date : Thursday, September 20, 2018

ManagementGroup Class (Microsoft.Azure.Management.OperationalInsights.Models) - Azure for .NET Developers

https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.management.operationalinsights.models.managementgroup A management group that is connected to a workspace
Published Date : Thursday, September 20, 2018

ManagementGroup.Sku Property (Microsoft.Azure.Management.OperationalInsights.Models) - Azure for .NET Developers

https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.management.operationalinsights.models.managementgroup.sku Gets or sets the SKU of System Center that is managing the management group.
Published Date : Thursday, September 20, 2018

ManagementGroup Constructor (Microsoft.Azure.Management.OperationalInsights.Models) - Azure for .NET Developers

https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.management.operationalinsights.models.managementgroup.-ctor Initializes a new instance of the ManagementGroup class.
Published Date : Thursday, September 20, 2018

Step by step - Deploy Windows 10 using Microsoft Endpoint Configuration Manager - Windows Deployment

https://docs.microsoft.com/en-us/windows/deployment/windows-10-poc-sc-config-mgr Deploy Windows 10 in a test lab using Microsoft Endpoint Configuration Manager
Published Date : Tuesday, September 15, 2020

Service connections in Azure Pipelines & TFS - Azure Pipelines

https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints Service connections in Azure Pipelines and Team Foundation Server (TFS)
Published Date : Thursday, May 14, 2020

Moving application authentication from AD FS to Azure Active Directory

https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/migrate-adfs-apps-to-azure This article is intended to help organizations understand how to move applications to Azure AD, with a focus on federated SaaS applications.
Published Date : Wednesday, April 1, 2020

Azure Compute - Linux Diagnostic Extension

https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/diagnostics-linux How to configure the Azure Linux Diagnostic Extension (LAD) to collect metrics and log events from Linux VMs running in Azure.
Published Date : Thursday, December 13, 2018

SAP on Azure: Planning and Implementation Guide

https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/planning-guide Azure Virtual Machines planning and implementation for SAP NetWeaver
Published Date : Monday, August 17, 2020

Azure Active Directory general operations guide reference

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-ops-guide-ops This operations reference guide describes the checks and actions you should take to secure general operations
Published Date : Thursday, October 31, 2019

Azure security baseline for Linux Virtual Machines Windows Virtual Machines - Azure Windows Virtual Machines

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/security-baseline The Windows Virtual Machines security baseline provides procedural guidance and resources for implementing the security recommendations specified in the Azure Security Benchmark.
Published Date : Monday, July 13, 2020

Azure Linux VM Agent Overview

https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/agent-linux Learn how to install and configure Linux Agent (waagent) to manage your virtual machine's interaction with Azure Fabric Controller.
Published Date : Monday, October 17, 2016

Planning for an Azure File Sync deployment

https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-planning Plan for a deployment with Azure File Sync, a service that allows you to cache a number of Azure file shares on an on-premises Windows Server or cloud VM.
Published Date : Wednesday, January 15, 2020

Microsoft Antimalware Extension for Windows VMs on Azure

https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/iaas-antimalware-windows Deploy the Azure Antimalware extension on Windows virtual machine using an extension.
Published Date : Thursday, April 12, 2018

Deploy the Azure Stack HCI operating system - Azure Stack HCI

https://docs.microsoft.com/en-us/azure-stack/hci/deploy/operating-system This article discusses different ways to deploy the Azure Stack HCI operating system, and then use Windows Admin Center to connect to your servers. Reference to related guidance on creating a server cluster is included, as well as optional steps to get the latest Windows updates and firmware for your servers.
Published Date : Wednesday, September 9, 2020

https://docs.microsoft.com/en-us/learn/modules/manage-windows-10-through-co-management-by-using-system-center-configuration-manager/ Co-management is one of the primary ways to attach your existing Configuration Manager deployment to the Microsoft 365 cloud. It helps you unlock additional cloud-powered capabilities like conditional access.
Published Date : Wednesday, September 4, 2019

Simplify device management with Microsoft Endpoint Manager - Learn

https://docs.microsoft.com/en-us/learn/modules/simplify-device-management-with-microsoft-endpoint-manager/ Learn about the business management solutions offered as a part of Microsoft 365 and how they can help simplify management and contribute to organizational productivity.
Published Date : Wednesday, August 12, 2020

.NET Framework Deployment Guide for Administrators

https://docs.microsoft.com/en-us/dotnet/framework/deployment/guide-for-administrators Read the .NET deployment guide for administrators. Use this information to deploy .NET version 4.5 and its system dependencies across a network.
Published Date : Tuesday, April 10, 2018

Designing your Azure Monitor Logs deployment - Azure Monitor

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/design-logs-deployment This article describes the considerations and recommendations for customers preparing to deploy a workspace in Azure Monitor.
Published Date : Friday, September 20, 2019

Compare the database engine features of SQL Database and SQL Managed Instance - Azure SQL Database & SQL Managed Instance

https://docs.microsoft.com/en-us/azure/azure-sql/database/features-comparison This article compares the database engine features of Azure SQL Database and Azure SQL Managed Instance
Published Date : Wednesday, July 22, 2020

What's new in Azure Site Recovery - Azure Site Recovery

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-whats-new Provides a summary of new features and the latest updates in the Azure Site Recovery service.
Published Date : Thursday, August 20, 2020

Can't launch Service Manager console in Windows 7 32-bit - Service Manager

https://docs.microsoft.com/en-us/troubleshoot/system-center/scsm/console-cannot-launch Describes an issue in which the System Center Service Manager console fails to launch on a system running Windows 7 32-bit.
Published Date : Tuesday, August 4, 2020

Update 1603 for Cloud Platform System Standard - Azure

https://docs.microsoft.com/en-us/troubleshoot/azure/general/update-1603-cps-standard Describes Update 1603 for Cloud Platform System Standard. Includes updates for Windows Server 2012 R2, System Center 2012 R2, and Windows Azure Pack.
Published Date : Friday, August 14, 2020

Use-SCStopVM (VirtualMachineManager)

https://docs.microsoft.com/en-us/powershell/module/virtualmachinemanager/use-scstopvm The Use-SCStopVM cmdlet shuts down a virtual machine in System Center 2019 Virtual Machine Manager. This cmdlet changes the virtual machine to the Stopped state regardless of the current state.
Published Date : Tuesday, September 15, 2020

Use-SCSaveStateVM (VirtualMachineManager)

https://docs.microsoft.com/en-us/powershell/module/virtualmachinemanager/use-scsavestatevm The Use-SCSaveStateVM cmdlet changes a virtual machine from the Running state to the Saved state in System Center 2019 Virtual Machine Manager.
Published Date : Tuesday, September 15, 2020