Rejects a device update rule that has been imported to the system.
Syntax
Reset-CsDeviceUpdateRule [-Identity <XdsIdentity>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]] |
Reset-CsDeviceUpdateRule [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-Instance <PSObject>] [-WhatIf [<SwitchParameter>]] |
Parameters
| Parameter | Required | Type | Description |
|---|---|---|---|
|
Identity |
Optional |
String |
Unique identifier for the device update rule being reset. The Identity for a device update rule consists of a two parts: the service where the device update rule has been assigned (for example, service:WebServer:atl-cs-001.litwareinc.com) and a GUID (globally unique identifier). Consequently, a device update rule configured for the Redmond site will have an Identity similar to this: service:WebServer:atl-cs-oo1.litwareinc.com/d5ce3c10-2588-420a-82ac-dc2d9b1222ff9. |
|
Instance |
Optional |
DeviceUpdate.Rule |
Allows you to pass a reference to an object to the cmdlet rather than set individual parameter values. |
|
WhatIf |
Optional |
Switch Parameter |
Describes what would happen if you executed the command without actually executing the command. |
|
Confirm |
Optional |
Switch Parameter |
Prompts you for confirmation before executing the command. |
Detailed Description
Microsoft Communications Server 2010 uses device update rules as a way to provide firmware updates to devices (such as Tanjay telephones and the RoundTable conferencing station) that run Communicator “14” Phone Edition. Periodically, administrators upload a set of "device update" rules to Communications Server 2010; after those rules have been tested and approved, they are then automatically downloaded and applied to the appropriate devices as those devices connect to the system. By default devices check for new update rules each time they turn on and connect to Communications Server 2010; devices also check for updates every 24 hours after that initial sign-on.
Each new device update rule added to the system is marked as "Pending." That means that the update will be downloaded and installed by the appropriate test devices; however, it will not be downloaded and installed by client devices in general. This gives you an opportunity to test the updates and ensure that there are no adverse effects before you make this update widely available. As soon as you are convinced that the update is "safe," you can then use the Approve-CsDeviceUpdateRule to approve the update.
On the other hand, administrators might conclude that a given update should not be used in the organization (for example, the update might cause a conflict with in-house software). In that case, administrators can use the Reset-CsDeviceUpdateRule cmdlet to reject the update. When that happens, the PendingVersion of the update rule is set to a null value. In turn, that means that test devices that log on to the system will uninstall the update and reinstall the previous version of that update. And because the update was never approved, that means that the update will never be installed by anything other than test devices.That means that there will be no impact on the general user population.
The Reset-CsDeviceUpdateRule cmdlet can only be used for device update rules in the Pending state. If a rule has already been approved, you will need to use the Restore-CsDeviceUpdateRule cmdlet to roll back the deployment of the device update.
Return Types
Reset-CsDeviceUpdateRule resets instances of the Microsoft.Rtc.Management.WriteableConfig.Settings.DeviceUpdate.DeviceUpdate.Rule object.
Examples
-------------------------- Example 1 ------------------------
 Copy Code |
|
|---|---|
Reset-CsDeviceUpdateRule -Identity service:WebServer:atl-cs-001.litwareinc.com/d5ce3c10-2588-420a-82ac-dc2d9b1222ff9 |
|
The command shown in Example 1 resets the device update rule d5ce3c10-2588-420a-82ac-dc2d9b1222ff9 found on the service WebServer:atl-cs-001.litwareinc.com.
-------------------------- Example 2 ------------------------
| Copy Code |
|
|---|---|
Get-CsDeviceUpdateRule -Filter service:WebServer:atl-cs-001.litwareinc.com* | Reset-CsDeviceUpdateRule |
|
The preceding command resets all the device update rules that have been configured for the service WebServer:atl-cs-001.litwareinc.com. This is done by first calling Get-CsDeviceUpdateRule along with the –Filter parameter; the filter value "WebServer:atl-cs-001.litwareinc.com*" ensures that only rules that have an Identity that begins with the characters "WebServer:atl-cs-001.litwareinc.com" will be returned. (By definition, these are all the device update rules that have been assigned to the service WebServer:atl-cs-001.litwareinc.com.) The filtered collection is then piped to the Reset-CsDeviceUpdateRule cmdlet, which resets each rule in the collection.
-------------------------- Example 3 ------------------------
| Copy Code |
|
|---|---|
Get-CsDeviceUpdateRule | Where-Object {$_.Brand -eq "LG-Nortel"} | Reset-CsDeviceUpdateRule
|
|
The command shown in Example 3 resets all the device update rules for the brand LG-Nortel. To do this, the command first calls Get-CsDeviceUpdateRule (without any parameters) in order to return a collection of all the device update rules currently in use in the organization. This collection is then piped to the Where-Object cmdlet, which picks out only those rules where the Brand property is equal to (-eq) LG-Nortel. After that the filtered collection is piped to Reset-CsDeviceUpdateRule, which proceeds to reset all the rules in the filtered collection.