<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>UEM Information Hub Blog</title>
        <link>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem</link>
        <description>UEM Information Hub Blog</description>
        <lastBuildDate>Wed, 22 Apr 2026 00:00:00 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>en</language>
        <item>
            <title><![CDATA[SCCM Client Agent not installing during autopilot]]></title>
            <link>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/265079</link>
            <guid>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/265079</guid>
            <pubDate>Wed, 22 Apr 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Problem Record 265079 SCCM Client Agent not installing during autopilot]]></description>
            <content:encoded><![CDATA[<p>Problem Record <a href="https://service.tamu.edu/SBTDNext/Apps/34/Tickets/TicketDet?TicketID=265079" target="_blank" rel="noopener noreferrer">265079</a> SCCM Client Agent not installing during autopilot</p>
<p>Jon reported that the SCCM agent was taking a long time to install for the OAL Self Driven Autopilot enrolled devices. During the investigation and discussion we discovered that the Intune Enrollment Co-management settings were no longer applied to anything. This used to be assigned and is no longer assigned. In an effort to fix this issue we assigned it to the device scope group for all autopilot enrolled devices. After making this emergency change Jon tested it and found that it was now working as expected for the OAL self driven devices. But a few days later I became aware that the user driven autopilot was no longer working. During the investigation and troubleshooting I created a duplicate Intune Autopilot deployment profile with identical settings and replicated all the assigned groups to the new deployment profile named "_TAMU User Driven with Pre Provision v2". I then forced a autopilot enrollment sync and it successfully switch all autopilot enrollment devices over to the new profile. But this did not resolve the issue. I pulled the autopilot enrollment logs and found that it was erroring out during the sccm client installation. I was able to determine that the emergency change to assign the Co-management settings to all autopilot enrolled devices was the cause. This emergency change has been adjusted to only target the OAL and UEM devices as well as a test device and test user. I am continuing to investigate this to find out why this is not working as intended. The User driven autopilot devices are now working as expected. This downtime occurred on 7/3 and 7/4. Devices were still able to finish out the autopilot enrollment with the availability of the continue on error option. This only effected devices going through the autopilot enrollment process.</p>]]></content:encoded>
            <category>Problem Record</category>
        </item>
        <item>
            <title><![CDATA[Pending Management Commands Issue]]></title>
            <link>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/426394</link>
            <guid>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/426394</guid>
            <pubDate>Wed, 22 Apr 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Problem Record 426394 Pending Management Commands Issue]]></description>
            <content:encoded><![CDATA[<p>Problem Record <a href="https://service.tamu.edu/SBTDNext/Apps/34/Tickets/TicketDet?TicketID=426394" target="_blank" rel="noopener noreferrer">426394</a> Pending Management Commands Issue</p>
<p>Overview:
While reviewing the Jamf server, we identified a device with an expired MDM renewal command that was still checking in and submitting inventory updates. Upon investigation, we discovered that the computer had a backlog of older pending MDM commands which had not yet been sent to the device. This backlog prevented the renewal MDM command from being processed, ultimately resulting in the device’s MDM profile expiring. As a result, the device is unable to receive any new MDM commands.</p>
<p>We identified approximately 45 devices in a similar state—they have submitted inventory within the last 60 days, but their MDM profiles have expired (<a href="https://tamu.jamfcloud.com/advancedComputerSearches.html?id=543&amp;o=r" target="_blank" rel="noopener noreferrer">https://tamu.jamfcloud.com/advancedComputerSearches.html?id=543&amp;o=r</a>)</p>
<p>Identity:
--User groups affected:&nbsp;<a href="https://tamu.jamfcloud.com/advancedComputerSearches.html?id=543&amp;o=r" target="_blank" rel="noopener noreferrer">https://tamu.jamfcloud.com/advancedComputerSearches.html?id=543&amp;o=r</a></p>]]></content:encoded>
            <category>Problem Record</category>
        </item>
        <item>
            <title><![CDATA[Jamf Pro database errors - smart group usage]]></title>
            <link>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/633742</link>
            <guid>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/633742</guid>
            <pubDate>Tue, 31 Mar 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Problem Record 633742 Jamf Pro database errors - smart group usage]]></description>
            <content:encoded><![CDATA[<p>Problem Record <a href="https://service.tamu.edu/TDNext/Apps/34/Tickets/TicketDet?TicketID=633742" target="_blank" rel="noopener noreferrer">633742</a> Jamf Pro database errors - smart group usage</p>
<p>Jamf engineering team messaged the Apple UEM team via email to let us know they noticed more SQL batabase errors than normal on the server, as well as reports of degradation from other Jamf teams. They investigated and concluded that the largest controbuting factor was the number of smart groups, especially the number that had no payload involved. The Apple team corroborated these numbers as well as the large number of smart groups that housed nested smart groups. This can cause recursive reporting and further increase server issues.</p>]]></content:encoded>
            <category>Problem Record</category>
        </item>
        <item>
            <title><![CDATA[Proofpoint agent popup after configuration change]]></title>
            <link>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/267956</link>
            <guid>https://tamu-edu.github.io/UEM-Information-Hub/blog-problem/267956</guid>
            <pubDate>Mon, 26 Jan 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Problem Record 267956 Proofpoint agent popup after configuration change]]></description>
            <content:encoded><![CDATA[<p>Problem Record <a href="https://service.tamu.edu/TDNext/Apps/34/Tickets/TicketDet?TicketID=267956" target="_blank" rel="noopener noreferrer">267956</a> Proofpoint agent popup after configuration change</p>
<p>Overview:<br>
<!-- -->[Description of the Problem]</p>
<p>Chronology:<br>
<!-- -->[Time details as to when the Problem occurred or how often it is recurring]</p>
<p>Identity:
--Services affected:
--User groups affected:
--Affected hardware, software, website, or devices:
--What related items are still functional?</p>
<p>Location:<br>
<!-- -->[Where does the problem occur?  Which building?  Which website?  Where within the building or website?]</p>
<p>Scope:<br>
<!-- -->[What is the extent of the Problem?  How many are affected?]</p>
<p>Sample User Data:
[NetIDs or affiliations of affected users.]</p>
<p>Additional Info:
--Troubleshooting already attempted:
--Recent related changes:
--Observational reports:
--Inclement weather:
--Other:</p>]]></content:encoded>
            <category>Problem Record</category>
        </item>
    </channel>
</rss>