Using Guaranteed State

Guaranteed State allows us to check our environment against a desired configuration and remediate any devices that do not meet that desired configuration. We use a combination of Policies and Rules to accomplish this with Tachyon. Behind the scenes fragments come into play, we will work with those in the lab for TIMS.

Configuring Tachyon for Guaranteed State

We have already set up our Guaranteed State Administrator and our Guaranteed State Viewer role in Tachyon. We have already used the Tachyon Product Pack Deployment Tool to import our Integrated Product Packs for Guaranteed State. This also imported the objects we will reference, such as our rule triggers and some default Check and Fix Rules.

Exploring Guaranteed State Application

In this task we will look at the different nodes in the Guaranteed State Application as both the Guaranteed State Administrator and the Guaranteed State Viewer

1. Still logged into 1ETRNW72 as 1ETRN\Manager1
2. Open the Tachyon Portal and Launch Guaranteed State
The Guaranteed State Administrator can also go directly into Guaranteed State https://tachyon.1etrn.local/tachyon/app/#/guaranteedstate this is especially useful if your Guaranteed State Administrator has no other role in Tachyon
3. Navigate to Overview look at the different tiles. We will visit these again later after we have deployed some policies. They will all be blank until we have assigned and deployed our policies
4. Notice the drop-down at the top defaults to All Policies, we can also select the different policies we have imported via the Product Pack Deployment Tool
5. Navigate to Administration – Policies. Notice we have three policies. This was from our import
6. Select the Windows Client Health policy and click the Assign button on the far right
7. In the Assign Management Groups screen – Start to type All Dev in the Search for Management Groups
8. Click the All Devices Management Group when it resolves. Click Save
9. Select the Microsoft SCCM Client Health and assign it to All Devices
10. We have now assigned policies
11. Once you have assigned the Policies to your Management Group you must now click Deploy
12. Click Yes on the Are you sure box
13. Navigate to Rules node. Notice the rules that we imported
14. Click View Details on the ConfigMgr Client running. In the pop-up notice this is a Check Rule that will query the device to see that the Config Man Client Service is running. Notice the Trigger – this query will run if the state of the SMS Agent Host Service changes. Notice the Pre-Condition – it will only run on devices that have the Config Man Client installed
15. View Details on some of the rules to get an understanding of what they do
We will log into Guaranteed State as our account that is only a Guaranteed State Viewer, once we have some data to see the differences in the access permissions.

Viewing the Results of a Policy

Now that we have our policies assigned to a management group and deployed, we can look at the results of that policy.

16. Still logged in as 1ETRN\Manager1
17. Navigate to Overview
18. Notice the top drop-down on the far right – We have All Policies Selected. We could select a specific policy to view the results for that policy only. Leave it at all policies for now
19. On the top row there is a Tile – Device State – Hover over the  icon. Read the information about this tile
20. Hover over each slice of the pie chart to view the actual number of devices in each state. We may have some devices in Unknown state until they finish evaluating the policies that we have just deployed
21. Click on the slice of the pie for Non-compliant. Notice how it builds our filter for us and takes us to the devices report for the ones that are State Noncompliant
22. Click on View History. Scroll down to see which check failed. Click close
23. Go back to Overview. Look at the next Tile – Device State per Criticality Level. Hover over the  icon to read the information about the tile. This tile shows a bar chart of the state of our devices but based on the Criticality of the Device that we have assigned
Remember that we set our device criticality in the Explorer Application when we were working with Instructions. Tachyon allows us to assign Criticality Levels to devices – much the same way that Microsoft assigns classifications to security update to set the importance level of that update. You might label your Domain Controllers as Critical while a File Server might be set as Low. We can use this to report on status in Guaranteed State. In the Explorer Application we can use this attribute to define coverage for an instruction.
24. The, Last Seen tile shows the time the devices last checked in with the Tachyon Server. All seven of our devices should show in the current column. If they do not, drill into the chart and make sure the device is powered on. When you click on one of the bars notice that it creates a filter for you and takes you to the results of the filter
25. Click the back button or navigate back to Overview
26. Look at the Rule Effectiveness tile which shows rules that are being used in the environment. Hover over the  icon and read the details
This is a very good tile to use in production. When we have rules or policies in our environment (think of Group Policy or Config Man Compliance Settings) it is nearly impossible to determine if specific policies or baselines are still needed so after time you end up with hundreds, if not thousands of them and no way to tell if you really need them. This tile will show you the polices that are disabled and ones that are not deployed. That is good information to have but the real value here are the Ineffective category. These are the policies that have not changed their compliance position changed in the last 30 days. No devices that are assigned that policy have had any movement either they are still compliant or still non-compliant. The policy may not be needed anymore or might not be remediating the issue correctly. The last category – Effective shows all the policies that have had devices that have changed their position in the last 30 days – so they either moved from compliant to Non-Compliant or from Non-compliant to compliant.
27. Look at the two tiles – Rule Status and Rule Remediations Last 7 Days
28. Navigate to Administration – Polices. Notice the number of rules in each policy. Guaranteed State calls the device non-compliant for that policy if any of the rules are not compliant
29. Navigate to Administration – Rules and scroll to find where the Rule type is Fix, and notice the Red in the enabled field. The Tachyon Product Pack Deployment Tool imports in the Fix rules but makes them disabled. Only the check rules are enabled. This ensures that changes to devices will not occur if the environment needs to follow a change control process. We do not need to enable the fix rules for our lab as we do not have Nomad installed and all the fixes are for the Nomad policy. You will want to enable them in your environment if you want the Nomad items corrected.
30. Navigate to Reports – Policies. Here you can see the details on the devices and how many are compliant or noncompliant
Notice that we did not assign or deploy the Nomad Client Health policy as we do not have Nomad installed in this lab

Working with Policies, Rules, and Triggers

Policies that contain one or more rules are assigned to Management Groups and deployed. There two primary types of rules – Check Rules and Fix Rules. Check Rules query the device for a specific state and Fix Rule are used to remediate that device based on the state an Administrator wants to maintain. In this task we will build a Registry Policy. We see applications that need specific settings to function properly. This policy is an example of how to monitor applications to make sure they have the proper configurations or even change the configurations when necessary.

Create A Registry Rule

31. In Guaranteed State, navigate to Administration – Rules
32. Click New in the far right. In the Name field type in My Application Registry
33. In the Description window type in Rule to ensure the My Application Registry is set to 7
34. In the Type field select Check
35. Click on Triggers
Triggers tell the Tachyon Agent when to run the check rule – so when to perform that query. Notice that we can do this check on a timed interval, but we can also do this check each time something changes on the devices (Service state changes, file changes, registry key changes, event log entry, process start up, security event, etc). The interval check should rarely be used as this is just an arbitrary cycle and will use processing power on the device to run the query even if it is not needed. The value of Guaranteed State is the ability to look for the specific change and only run your rule at that time – if my policy says a service should be started it is a waste of the device to run that check every hour when I could set my trigger to only run if the state of that specific service changes.
36. Click the Drop-down to see the list of available Triggers. Select When a Registry Key Changes (you may need to scroll to see this option)
37. We need to add our Registry Key for this task
38. Leave Guaranteed State as it is and Click Start button – in the Search Type in Regedit
39. Open Regedit and Navigate to HKEY_Local_Machine\Software
40. Right Click on Software and choose New - Key. Name the key MyApplication
41. Right Click on MyApplication and Create a New DWord Value
42. Rename New Value #1 to MySettings. Notice our value is set to 0 – we will leave it like that and let Guaranteed State fix it for us
43. Minimize Regedit. Back in Guaranteed State – In the Hive box select HKLM
44. In the Subkey box type in Software\MyApplication
45. In the Include Subkeys box choose true
46. This will tell the Tachyon Agent to monitor this Registry Key for changes – if it changes it will then run our rule to check to make sure the device is still configured properly
47. We will not set a Pre-Condition check on this rule
Precondition check would be appropriate for this one in the real world as we could set this to only run if our application in question was installed.
48. Look at the Precondition check options that are available but leave without setting one since in our lab we do not have an application install to go with our fake registry key
49. Click on Check – in the Select Check box select Check that registry key <hive>\<Subkey>\<Name> has <valueType> value of <value>
50. In the Hive box select HKLM
51. In the Subkey box type in Software\MyApplication
52. In the Name box type in MySettings
53. In the Value box type in 7
54. In the Value Type box select Reg_DWord
55. Click Save in the upper right
56. Navigate to Administration – Policies. Click on New in the far right
57. In the New Policy page, Name field type in My Application Registry
58. In the Description field type in My Application Registry
59. In the All Rules pane select our MyApplication Registry rule click the >> to move it over to Assigned Rules pane
60. Click Save. Notice we have a pop-up reminding us that our Policy has not been deployed
61. We will assign and deploy that now. Select our My Application Registry policy click Assign
62. Start typing Win and once suggested select the Windows 7 Management Group
We could repeat this to select multiple management groups
63. Click Save
64. Click Deploy. Click Yes on the Are you sure pop-up
65. Navigate back to the Overview Page. Click Refresh
66. Select the My Application Registry policy from the drop-down to view our tiles for only that policy
67. Notice our device state is Non-compliant for all three devices
68. Drill into the Device Status to see the individual devices
69. Click View History on each one to see the results for each machine
70. This is the expected result because we deployed to our three Windows 7 devices – two of them do not have the registry key and 1ETRNW72 has the key but with a 0 value

Watch Guaranteed State in Action

In this task we are going to work with our MyApplication Registry setting again but this time we are going to create the value if it does not exist. If it is set incorrectly, set it correctly. Again, this could help us in production with the applications in our environment that need specific settings to function correctly, this Policy will ensure that our application will function correctly even if something modifies the setting.

71. In Guaranteed State, navigate to Administration - Rules
72. Select the My Application Registry Rule click on Edit
73. Leave the Name field alone
74. Leave the Description alone
75. In the Type box change to fix
76. Leave the Trigger pane set
In addition to running based on the trigger that in configured – in our case when our MyApplication key changes - rules also run the initial time when they are deployed to the device.
77. Leave Precondition and Check panes alone and click on Fix
78. Now we will create the fix rule. Select the Set registry key <Hive>\<Subkey>\<Name> to <ValueType> value of "<Value>"
79. In Hive select HKLM
80. In the Subkey field type in Software\MyApplication
81. In the Name field type in MySettings
82. In the Value field type in 7
83. In the ValueType field select Reg_DWord
84. Click Save
85. Navigate to Administration – Policy click on Deploy at the top. Click Yes on the pop-up
86. Navigate back to Overview and Click Refresh
87. Once the devices have checked in you should see it change to all Green in device state with My Application Registry selected for the overview
88. Open regedit to check that the value has changed. You may need to refresh if you left it minimized. Log into the other Windows 7 devices to check them also
89. When you have completed the check – go back to 1ETRNW72 and change the registry value to 20. Right click on MySettings and choose Modify – type in 20. Click ok
90. Hit refresh and you will see Tachyon almost instantly change it back to 7
91. Go back into Guaranteed State
92. Navigate to Overview – Policy Rule Effectiveness – Click on the Effective Gear Icon
93. It will take you to the Rules page with our MyApplication Registry rule filtered
94. Click on the MyApplication Registry Rule. It will take you to our Devices page that is filtered for our deployed rule. Click on View History for 1ETRNW72. Notice the status entries as you changed it to 20 Hex which is 32 Decimal

Create a Service Rule

In this task we are going to create a policy that checks the state of the Remote Registry Service and starts the service if it is stopped. We are going to assign this to our All Devices management group and deploy it but use a pre-condition to make it only run on Windows 10.

95. In Guaranteed State, navigate to Administration – Rules
96. In the New Rules pane – details tab – Name field type in RemoteRegistry Service
97. In the Description type in RemoteRegistry Service Started
98. In the Type field choose fix
99. In the Triggers tab select When the State of the named Windows Service changes
Note that we could select multiple triggers by click in the + sign and adding additional triggers.
100. In the Service Name field type in RemoteRegistry
101. Click the Precondition tab and choose Run if Device is Windows <minimum version>
102. In the Minimum Version field select 10 or greater from the list
103. Click on Check tab and select Check that service <ServiceName> is <state>
104. In the ServiceName field type in RemoteRegistry
Make sure you type in RemoteRegistry for the service name without a space or your rule will fail.
105. In the State field select Running
106. Click the Fix tab and choose Request service "<Short name of service>" to <Service action to perform>
107. In the ServiceName field type in RemoteRegistry
108. In the Action field select Start
109. Click Save
110. Navigate to Administration – Policies and Create a Remote Registry Policy that contains our Remote Registry Rule. Save the policy
111. Assign to our All Devices Management Group and then deploy
112. Navigate to Overview – select our Remote Registry Policy
113. Hit refresh until you begin to see results
114. Look at the state of the devices

115. Open file explorer and look at c:\ProgramData\1E\Client\1E.Client.log. Notice how the policy is downloaded, checked against our certificates, and then processed by the agent
116. Now Open the Services Applet and stop the Remote Registry Service
117. Watch the 1E.Client.log as this happens
118. Look for our Remote Registry Policy and see how the check fails when we stopped the service and Tachyon will run the Fix rule to start the service

Guaranteed State as a Viewer

In this task we will look at Guaranteed State as a Viewer

119. Log into 1ETRNW101 as 1ETRN\User
120. Launch the Tachyon Portal
121. Switch App to Guaranteed State
122. Navigate to Overview. Look at the tiles for each Policy that we have configured
123. Drill into the tiles
124. Navigate to Administration – Rules. Notice that this user can see all the rules but has no ability to create or deploy them
125. Notice that within Rules you can drill into the View Details
In this lab we worked with Rules- both Check rules that just run a query for device state, and Fix rules that act to remediate the device if the check rule fails. We also looked at triggers, these are what tell the Tachyon Agent when to run a specific rule. We used Precondition checks to target our rules at only applicable devices (i.e. a Policy to fix a registry key for a specific application should only be needed to run on devices that have that application installed). We also looked at the Guaranteed State application as our user that is only a viewer. We will revisit Guaranteed State again when we work with TIMS.

Lab Summary

In this lab we looked at the Guaranteed State Application. We explored the application and then deployed polices to devices and observed the results when a device did not meet a condition. We then saw how the Guaranteed State Application reported on our device status in near real-time.

Next Page

Ex 9 - TCN Opr v5.0 - Microsoft Configuration Manager Integration