Tagged: SCCM

Microsoft’s New Intune Troubleshooting Portal is a Real Plus For Useful Support

Microsoft’s Intune product is not something that I have blogged much about, in fact this is the first blog I’ve ever written on the product. But that’s all about to change….

Microsoft Intune was originally designed as an online “Lite” version of System Center Configuration Manager for those smaller organisations with a very mobile workforce. It was very slow to gain much momentum as many organizations already has System Center Configuration Manager and could not see the value for the product.

Over the years Microsoft have slowly but surely moved focus of the Intune product to a more Mobile Device Management focus and even started to integrate in a “Hybrid” method in to System Center Configuration Manager. (More on this in later blog posts)

In late October this year (26th October 2016 to be precise) the Enterprise Mobility and Security team announced a new Troubleshooting Portal for the Azure platform.

This new troubleshooting portal provides analysts with a range of critical data exactly when and where they need it to resolve issues for end users who may be experiencing issues with their Intune connected mobile devices.

As the Microsoft Intune Team says in their announcement blog post:

Having the right data at your fingertips is a must when you’re troubleshooting issues with your end users. Intune’s new Troubleshooting Portal provides a “single pane of glass” for reviewing device status, assignments and policies affecting a user, eliminating the need to click into multiple workloads to diagnose issues.

…..this is a big win for IT Pros and Support or Helpdesk workers who want resolve end user issues faster with less effort.

The user details that an analyst can view for each user are:

  • User status
  • Group assignment
  • Application and policy assignments
  • App protection status
  • Compliance issues
  • Device status
    and
  • Device details (Such as OS type and version)

But I don’t want to give my Helpdesk staff access to my Intune environment!

No worries there.

Intune’s inbuilt Role Based Access Control (RBAC) solution allows for admins to grant access to support and helpdesk staff to just the items that they require and nothing else. The inbuilt Helpdesk Operator role grants members access to end users assignments, policies devices apps etc. and even see if their devices are registered in AD and in the future you will even be able to see applications installation status and enrollment status of devices.

Getting access to this level of information on the helpdesk at the time of a users call to the service desk is very powerful to assist staff in resolving any issues at first contact and getting your end users back to fully functional work as soon as possible.

If only Configuration Manager had a nice friendly website that we could give easy RBAC access to for Helpdesk and Support staff to get basic troubleshooting information without them needing the console or giving away the keys to the ConfigMgr kingdom……   Oh wait….   I’m sure I’ve blogged about that before…..  🙂

 

Advertisements

A New Way to Look at System Center Configuration Manager

If you are like me and have spent many years (even decades) looking at the Configuration Manager console you probably can’t think that there could possibly be any other way to do you work on a day-to-day basis. Navigating the Configuration Manager console becomes second nature after a while and we don’t really think about it.

However, what if there was a new way to look at the Configuration Manager console that was easy to teach new staff members to learn and use, gives staff members access to just the features they need (and no more) and is available everywhere we need it without needing an app installed?

Well now there is!

Cireson, Your System Center Experts, have announced the Cireson Portal for Configuration Manager. It is a web-based experience to help manage and standardise daily tasks outside of the native Configuration Manager Console. This new approach to the ConfigMgr console empowers everyone on your IT team with anywhere, anytime access to inventory data, collection membership, software management and deployment, OSD management and deployment, and more.

Full Disclaimer: At this point I want to make the disclaimer that I work for Cireson. I also want to point out that I have worked with ConfigMgr since SMS v2.0 and that I will try my utmost to not let my involvement with Cireson colour my judgement of this tool and what it means for the SysAdmin’s daily workload.

With that out of the way….. This product is the best thing since ADR’s!

Any admin who uses ConfigMgr on a daily basis knows what a HUGE relief it was when we got ADR’s in the 2012 release of ConfigMgr. It saved us hours of packaging and testing and mucking about. In my opinion, the Cireson Portal for Configuration Manager is the most important innovation to the administration of  ConfigMgr since ADR’s were introduced.

Why am I so confident about this portal and it’s claims? The answer is that it is build is being directed and overseen by Wally Mead himself. For anyone involved ins the Configuration Manager world for more than 5 minutes knows who Wally is, but in case you don’t Wally was involved with the ConfigMgr product within Microsoft for 22 years and literally wrote the book on all things ConfigMgr. So when I say this solution has pedigree, you know I mean it.

Enough talk, let’s take a look at some of the ways the Configuration Manager Portal changes the way people will use and interact with ConfigMgr on a daily basis.

If you are a ConfigMgr admin in Australia, no doubt you know, and often tell stories at dinner parties, about the incident where “SCCM Task Sequence blew up Australia’s CommBank” also reported as “Disastrous patch cripples CommBank“. Many ConfigMgr admins shudder at the thought of how easy this mistake was and often bring this up when explaining to their managers why they don’t want to give Service Desk or other IT teams access to the ConfigMgr console.

The Configuration Manager Portal is designed to give Configuration Manager Admins what they have always dreamed of… a way to easily give others access to the parts of Configuration Manager they require and nothing else! With the Configuration Manager Portal, Admins can easily configure targeted access for different Analyst Groups using Role-Based Access Control (RBAC) so that these Analysts can add Configuration Manager to their tool belt and maximise the value they bring to the business without the keys to the kingdom….   and potential disaster.

At the core of why the Configuration Manager Portal is it is a localized web-based portal and therefore there is no Configuration Manager Console deployment that needs to be created and maintained. Also it is a simplified interface that makes it easy to use and intuitive, thereby reducing the time that is required to spend on training Analysts.

cmp-security

Easy to scope security for all support teams

Don’t get me wrong, the Configuration Manager Portal is not designed to replace the OOB Configuration Manager Console for actual Configuration Manager Administrators. The traditional console has everything and admin needs to not only operate day-to-day, but also upgrade, plan, expand, migrate etc. But for non-admins, or non-admin tasks, the Configuration Manager Portal is perfect to get in and get the job done.

What about a specific example?

For many organisations, the Service Desk (Level 1 Support) is a volume business.  Time management and efficiency are the keys to success for incident and request triage, first-call resolution, and escalation. Correctly gathering and analysing required information about an incident or service request in an expedient manner allows for a faster resolutions or fulfillment of service.

Leveraging the Cireson Portal for Service Manager with the Configuration Manager Portal gives Service Desk Analysts the tools they need to gather and analyze the info they need to do their jobs more efficiently. Upon receiving an Incident Request, they can quickly use the Configuration Manager Portal to gain information on affected resources such as:

  • User Device Affinity lookup and edit
  • Current Inventory
  • Software Deployment Status

The Service Desk Analyst can also use the Configuration Manager Portal to initiate a Software Deployment on demand if you as the admin allows it via RBAC right.

intro-browse-computers-right-click-1

Simple console interface from any browser

What about Desktop Support or the Server team?

Desktop Support staff spend much of their time away from their assigned workstations resolving issues and providing services at the end user’s location. Having to access a locally installed Configuration Manager Console can add unnecessary time when needing to get the end user back to being productive. Server Support teams put a premium on time, especially when dealing with server outages. Therefore, Server Analysts need quick access to information and remediation tools for servers either from their desk or in the Data Center, and sometimes from remote locations.

Having a web based ConfigMgr console allows Desktop and Server teams to:

  • Get software update status and apply patches when necessary
  • Deploy or upgrade software, if required
  • Deploy a new OS Image to a computer or server
  • Migrate a computer to an new OS (such as Windows 10 + Office 365) using MDT
  • View reporting for all of the above
cmp-software

Easily deploy software, even when not at your desk.

Finally, Managers can easily report and track the overall health of the organisation using simple to access dashboards to get a high level view of the entire IT operation.

Watch a sneak peek of the solution featuring Cireson Co-Founder, Shaun Ericson, and Microsoft MVP, Wally Mead. View now.

The Cireson Portal for Configuration Manager will be generally available in early 2017. Learn more and sign-up for first-priority access here.

Getting More From ConfigMgr For SCSM

We all love Microsoft’s System Center Configuration Manager and the vast majority of the industry loves it too. As Microsoft have recently announced over 50Million end points are now covered by just the latest current branch build (1610) https://blogs.technet.microsoft.com/enterprisemobility/2016/11/18/configmgr-current-branch-surpasses-50m-managed-devices/?Ocid=C+E%20Social%20FY17_Social_TW_MSFTMobility_20161128_685262993

The amount of data points that are returned from the ConfigMgr client is huge and can be exceptionally useful when diagnosing issues or tracking down what is deployed in an organization.

However, out of the box, the data is limited to what Microsoft deem necessary. While this is fine for much of the time every now and then there is a requirement to find more or different information to track things that are not in the standard hardware inventory report.

A great example that was asked for recently is Monitors.

Some organizations want to be able to track monitors with their PC’s and therefore their locations etc.

What many people do not realise is that a monitors cable (even VGA) passes very basic information back to the PC. This data can contain a bunch of data that is relevant to the monitor such as:

  • Manufacturer
  • Model
  • Serial Number
  • Etc.

This data is an industry standard called Extended Display Identification Data (EDID). This data is in a consistent format so this allows us to be able to retrieve this data in a consistent way.

Once we retrieve the data we can use it to identify what Monitor is currently plugged in. All we then have to do is get the Configuration Manager client to return the data as part of the standard hardware inventory cycle.

Step 1: Storing the EDID Data Somewhere Locally

This step takes the EDID data and places it in to a location that we can simply retrieve via the ConfigMgr client.

To achieve this, we need to get the client to interrogate the monitor for the EDID information then save the data to an easy to retrieve location, such as the WMI of the local machine.

To do this, we use PowerShell.

Here is the code you will need:
Test this script before you use it in prod. The script is provided as is and is not supported. (The usual drill)

# Reads the 4 bytes following $index from $array then returns them as an integer interpreted in little endian
function Get-LittleEndianInt($array, $index) {

# Create a new temporary array to reverse the endianness in
$temp = @(0) * 4
[Array]::Copy($array, $index, $temp, 0, 4)
[Array]::Reverse($temp)

# Then convert the byte data to an integer
[System.BitConverter]::ToInt32($temp, 0)
}

# Creates a new class in WMI to store our data including fields for each of the data points that we can return
function Create-Wmi-Class() {
$newClass = New-Object System.Management.ManagementClass(“root\cimv2”, [String]::Empty, $null);
$newClass[“__CLASS”] = “MonitorDetails”;
$newClass.Qualifiers.Add(“Static”, $true)
$newClass.Properties.Add(“DeviceID”, [System.Management.CimType]::String, $false)
$newClass.Properties[“DeviceID”].Qualifiers.Add(“key”, $true)
$newClass.Properties[“DeviceID”].Qualifiers.Add(“read”, $true)
$newClass.Properties.Add(“ManufacturingYear”, [System.Management.CimType]::UInt32, $false)
$newClass.Properties[“ManufacturingYear”].Qualifiers.Add(“read”, $true)
$newClass.Properties.Add(“ManufacturingWeek”, [System.Management.CimType]::UInt32, $false)
$newClass.Properties[“ManufacturingWeek”].Qualifiers.Add(“read”, $true)
$newClass.Properties.Add(“DiagonalSize”, [System.Management.CimType]::UInt32, $false)
$newClass.Properties[“DiagonalSize”].Qualifiers.Add(“read”, $true)
$newClass.Properties[“DiagonalSize”].Qualifiers.Add(“Description”, “Diagonal size of the monitor in inches”)
$newClass.Properties.Add(“Manufacturer”, [System.Management.CimType]::String, $false)
$newClass.Properties[“Manufacturer”].Qualifiers.Add(“read”, $true)
$newClass.Properties.Add(“Name”, [System.Management.CimType]::String, $false)
$newClass.Properties[“Name”].Qualifiers.Add(“read”, $true)
$newClass.Properties.Add(“SerialNumber”, [System.Management.CimType]::String, $false)
$newClass.Properties[“SerialNumber”].Qualifiers.Add(“read”, $true)
$newClass.Put()
}

# Check whether we already created our custom WMI class on this PC, if not, create it
[void](Get-WmiObject MonitorDetails -ErrorAction SilentlyContinue -ErrorVariable wmiclasserror)

# If the wmiClassError is returned then assume that the WMI class does not exist yet and try to create a WMI class to hold the Monitor info
# If creating the WMI class fails, exit with error code 1
if ($wmiclasserror) {
try { Create-Wmi-Class }
catch {
“Could not create WMI class”
Exit 1
}
}

# Iterate through the monitors in Device Manager
$monitorInfo = @() #Empty array
Get-WmiObject Win32_PnPEntity -Filter “Service=’monitor'” | foreach-object { $k=0 } {
$mi = @{}
$mi.Caption = $_.Caption
$mi.DeviceID = $_.DeviceID

# Then look up its data in the registry
$path = “HKLM:\SYSTEM\CurrentControlSet\Enum\” + $_.DeviceID + “\Device Parameters”
$edid = (Get-ItemProperty $path EDID -ErrorAction SilentlyContinue).EDID

# Some monitors, especially those attached to VMs either don’t have a Device Parameters key or an EDID value. Skip these
if ($edid -ne $null) {

# Collect the information from the EDID array in a hashtable
$mi.Manufacturer += [char](64 + [Int32]($edid[8] / 4))
$mi.Manufacturer += [char](64 + [Int32]($edid[8] % 4) * 8 + [Int32]($edid[9] / 32))
$mi.Manufacturer += [char](64 + [Int32]($edid[9] % 32))
$mi.ManufacturingWeek = $edid[16]
$mi.ManufacturingYear = $edid[17] + 1990
$mi.HorizontalSize = $edid[21]
$mi.VerticalSize = $edid[22]
$mi.DiagonalSize = [Math]::Round([Math]::Sqrt($mi.HorizontalSize*$mi.HorizontalSize + $mi.VerticalSize*$mi.VerticalSize) / 2.54)

# Walk through the four descriptor fields
for ($i = 54; $i -lt 109; $i += 18) {

# Check if one of the descriptor fields is either the serial number or the monitor name
# If yes, extract the 13 bytes that contain the text and append them into a string
if ((Get-LittleEndianInt $edid $i) -eq 0xff) {
for ($j = $i+5; $edid[$j] -ne 10 -and $j -lt $i+18; $j++) { $mi.SerialNumber += [char]$edid[$j] }
}
if ((Get-LittleEndianInt $edid $i) -eq 0xfc) {
for ($j = $i+5; $edid[$j] -ne 10 -and $j -lt $i+18; $j++) { $mi.Name += [char]$edid[$j] }
}
}

# If the horizontal size of this monitor is zero, it’s a purely virtual one (i.e. RDP only) and shouldn’t be stored
if ($mi.HorizontalSize -ne 0) {
$monitorInfo += $mi
}
}
}

#$monitorInfo
# Clear WMI
Get-WmiObject MonitorDetails | Remove-WmiObject

# And store the data in WMI
$monitorInfo | % { $i=0 } {
[void](Set-WmiInstance -Path \\.\root\cimv2:MonitorDetails -Arguments @{DeviceID=$_.DeviceID; ManufacturingYear=$_.ManufacturingYear; `
ManufacturingWeek=$_.ManufacturingWeek; DiagonalSize=$_.DiagonalSize; Manufacturer=$_.Manufacturer; Name=$_.Name; SerialNumber=$_.SerialNumber})

#”Set-WmiInstance -Path \\.\root\cimv2:MonitorDetails -Arguments @{{DeviceID=`”{0}`”; ManufacturingYear={1}; ManufacturingWeek={2}; DiagonalSize={3}; Manufacturer=`”{4}`”; Name=`”{5}`”; SerialNumber=`”{6}`”}}” -f $_.DeviceID, $_.ManufacturingYear, $_.ManufacturingWeek, $_.DiagonalSize, $_.Manufacturer, $_.Name, $_.SerialNumber
$i++
}

The script needs to run on each PC on a regular interval to keep the data up-to-date. This ensures that if a monitor gets added or removed from a PC then the information is updated on a regular basis. Save the PowerShell script to a location that can be used by SCCM as the source location of a package. This location will be referenced as the Source Location for the remainder of this procedure.

Open the System Center 2012 Configuration Manager console  clip_image001
Select the Software Library workspace  clip_image002
Expand the Application Management node and select the Packages node  clip_image003
Select the subfolder where the package will be created, right click and select Create Package from the drop down list  clip_image004
Enter the following information:

Name: Monitor Details Gather

Description: Extract the monitor EDID information from the client and store the data in WMI ready for collection by SCCM

Version: 1.0

Click the checkbox labelled The package contains source files and click Browse

 clip_image005
Enter the UNC path to the Source Location folder created earlier in this procedure.

Click OK

Once back on the package screen, click Next

 clip_image006
Select Standard Program and click Next  clip_image007
Enter the following information:

Name: Get Monitor Details

Command Line: get-monitor-details.ps1

Run: Normal

Programs can run: Whether or not a user is logged on

Click Next

 clip_image008
Leave all settings as default and click Next  clip_image009

Confirm the settings and click Next to create the package

When the package creation is completed, click Close

Within the console, right click on the package and select Distribute Content from the drop down list  clip_imageb001
Click Next  clip_imageb002
Click Add and select Distribution Point from the drop down list  clip_imageb003
Select the distribution points that require the content and click OK  clip_imageb004
Once all distribution points have been added, click Next  clip_imageb005
Confirm all the settings and click Next  clip_imageb006
When the Distribute Content Wizard is completed, click Close  clip_imageb007

Once the package is created we need to deploy it out on to run on a regular schedule on clients. The script does need to be run often as the monitors will move from PC to PC over time. How frequently is up to each organization and what they are trying to achieve.

To setup a deployment:

Within the console, right click on the package and select Deploy from the drop down list  clip_imagec001
On the label collection label click the Browse button  clip_imagec002
Select the collection that the script will be deployed to and click OK.

On the previous screen, click Next

 clip_imagec003
Confirm that the content has been distributed to a distribution point and click Next  clip_imagec004
Select Required as the installation type and click Next  clip_imagec005
On the schedule wizard screen, click New  clip_imagec006
Click the Schedule button  clip_imagec007
Select the start time for when the script will run on the workstations.

Select a custom interval and set this schedule to recur every 1 days.

Click OK.

 clip_imagec008
Click OK  clip_imagec009
Click Next  clip_imagec010
Leave all settings as default and click Next  clip_imagec011
Leave all settings as default and click Next  clip_imagec012
Confirm the settings and click Next to create the package  clip_imagec013
When the Deploy software wizard is completed, click Close  clip_imagec014

Step 2: Retrieve the WMI Data via ConfigMgr

Now that we have the data stored in the WMI we need to get the ConfigMgr client to return the data next time it does a Hardware Inventory of the clients.

To ensure it is possible to read the correct fields within ConfigMgr the WMI class needs to exist on at least one PC that you have access to.

Select a PC to run the script on and execute the PS1 file.

This PC will be used later to query the class that will allow System Center 2012 Configuration Manager to collect inventory from all other workstations.

Select the Administration workspace  clip_imaged001
Select the Client Settings node  clip_imaged002
Select the Default Client Settings item,
OR
a client settings item that affects all workstation clientsRight click and select Properties
 clip_imaged003
Select Hardware Inventory from the settings list  clip_imaged004
Click Set Classes  clip_imaged005
Click Add  clip_imaged006
Click Connect  clip_imaged007
Enter the Computer name that the script was run on earlier in this procedure and click Connect  clip_imaged008
Select the MonitorDetails class from the list and click OK.

If the MonitorDetails class is not there, then the script has not run successfully on the computer you are connecting to. Make sure you test the PowerShell script and repeat if necessary.

Once the class is selected, click OK on the remaining open windows

 clip_imaged009

This process tells the client to retrieve the WMI class that we just created an populated using our PowerShell script. Once this is set, it will not need to be revisited unless the client settings change or are recreated for any reason.

And there we have it.

The PowerShell script will go out and run against clients updating the WMI and as these clients report in their Hardware inventory the monitor details will appear in the resource explorer like any other hardware detail.

For many, this may enough as they will be able to report on the ConfigMgr database and get the results they are after. Others want a more thorough view of Asset Management and may want to pull this information in to their Asset management solution to show these relationships.

In my next blog post, I will go through how to use the Cireson Asset Management Solution to pull in this data, create or update a Hardware Asset item for each monitor and finally how to associate it with the computer it is plugged in to.