Lessons Learned #550: From a Support Case to Reusable Knowledge
Reaching Lessons Learned #550 is an important milestone for me. However, the value of this series is not only the number of articles published. Each article started with a technical question, an unexpected behavior, a support investigation, or a scenario that required additional testing and analysis. Some cases resulted in a configuration change. Others required a query, a script, a workaround, a product clarification, or a different troubleshooting approach. Over time, I have learned that resolving the immediate issue is only one part of the work. A support case becomes even more valuable when the knowledge gained during the investigation can help another engineer or customer facing a similar situation. Every support case may contain a lesson. The challenge is to identify it, validate it, and make it reusable. Identify the Reusable Lesson Not every detail from a support case needs to become an article. The first step is to identify the part of the investigation that may be useful outside the original scenario. This could be: an unexpected product behavior; a common misunderstanding; a diagnostic query; a troubleshooting method; a configuration requirement; a limitation that may not be immediately visible; a way to interpret a metric or error message; a test that helped confirm the technical explanation. For example, the specific customer environment may be unique, but the method used to distinguish CPU pressure from Data IO pressure may be useful in many other investigations. Similarly, the original application architecture may be complex, but the test used to isolate a network path may be simple and reusable. The objective is not to reproduce the complete support case. The objective is to extract the lesson that may help others. Explain the Symptom Clearly A useful technical article should begin with a behavior that readers can recognize. For example: Connections fail only from one application instance. Query duration increases after a service-tier migration. CPU reaches a high percentage, but the workload remains constrained by another resource. A failover restores normal operation without fully explaining the original cause. A monitoring result appears different from what was initially expected. A reader should be able to determine quickly whether the scenario resembles a problem they are investigating. Describe How the Conclusion Was Reached A solution is more useful when the reader understands how it was validated. For that reason, I normally try to explain: what was initially observed; which evidence was reviewed; which possibilities were considered; which tests were performed; what result supported the conclusion; which limitations remained. The objective is to provide enough context for the reader to understand why the conclusion is reasonable and under which conditions it applies. Separate Mitigation from Explanation A mitigation may restore service without fully explaining the technical cause. For example: restarting an application may reset the connection pool; a failover may disconnect blocking sessions; scaling may increase several resource limits simultaneously; recompiling a query may temporarily produce a better execution plan; reverting a deployment may remove the immediate impact. These actions can be valid and necessary. However, when converting the case into reusable knowledge, it is important to distinguish between: what restored normal operation; what was confirmed as the contributing condition; what remained unconfirmed. This distinction helps prevent a successful recovery action from being interpreted as a complete root-cause explanation. Include Something Practical The most useful articles normally provide something the reader can apply. This may be: a query; a script; a checklist; a sequence of tests; a monitoring recommendation; a comparison table; a list of questions to ask; an example of the expected and unexpected results. Even a short article can be valuable if it gives the reader a practical next step. For example, a troubleshooting article may suggest comparing: affected and unaffected periods; successful and unsuccessful connections; current and previous execution plans; CPU, Data IO, and log write utilization; the original and alternative network paths; behavior before and after one controlled change. The practical element is what transforms an explanation into a reusable resource. Document the Boundaries of the Conclusion A technical conclusion is more reliable when its limitations are clearly described. During a support investigation, the available evidence may not allow us to determine every detail. For example: the historical telemetry may be limited; the behavior may not be reproducible; the exact application request may not be identifiable; the test environment may differ from production; an internal implementation detail may not be externally visible. In these situations, it is useful to explain both what was confirmed and what could not be confirmed. For example: The behavior was reproduced only through the affected network path. The same endpoint and authentication method worked successfully through an alternative path. The tests confirmed that the network path was a relevant condition, although the available evidence did not identify the specific component responsible. This type of conclusion is precise, useful, and transparent. A Simple Model I Normally Follow When deciding whether a support investigation can become reusable knowledge, I normally consider the following sequence: Observe: What behavior was reported or measured? Clarify: What was the exact scope and impact? Investigate: Which evidence was relevant? Reproduce: Could the behavior be tested under controlled conditions? Validate: Which result supported or challenged the explanation? Mitigate: What action reduced the immediate impact? Conclude: What did the available evidence allow us to confirm? Share: Which part of the investigation may help someone else? Not every case follows these steps in the same order, and not every investigation provides a complete answer. However, this approach helps transform an individual technical experience into something that can be understood and reused. Questions That Help Identify a Lessons Learned Article Before writing an article, I normally consider questions such as: Was the behavior unexpected or difficult to interpret? Could the same question affect other Azure SQL users? Was there an important difference between the initial assumption and the final conclusion? Did the investigation produce a useful query, script, or test? Is there a limitation or condition that should be better understood? Can the scenario be explained without customer-specific information? What should another engineer or customer do when facing the same behavior? If the investigation provides a useful answer to one or more of these questions, it may contain a lesson worth sharing. Conclusion After 550 Lessons Learned articles, the most important lesson may be that technical support knowledge should not remain only inside an individual service request. A support case starts with an immediate need: understand the behavior, reduce the impact, and identify the appropriate next action. However, once the investigation is complete, we have an opportunity to go one step further. We can extract the reusable part of the experience, explain how the conclusion was reached, document its limitations, and provide something practical for the next person facing a similar situation. That is how an individual support case can become shared technical knowledge. Resolving a case helps one specific situation. Sharing the validated lesson may help many others avoid starting the same investigation from zero.Lessons Learned #551: Azure SQL Connection Timeouts: Three Things to Check
An application starts reporting intermittent timeouts when connecting to Azure SQL Database. Some requests succeed, others fail, and a test from a developer’s laptop works perfectly. The database appears online, no recent deployment seems related, and the natural reaction is to ask: Is Azure SQL unavailable? Is the firewall blocking the connection? Should we increase the connection timeout? Should we change the driver or scale the database? Those are reasonable questions, but they may lead the investigation in the wrong direction. The most important lesson is simple: A timeout tells us how long the application waited. It does not tell us what the application was waiting for. Not every “SQL timeout” happens inside Azure SQL From the application’s point of view, opening a database connection may involve several operations: Resolving the server name. Reaching the SQL endpoint. Obtaining a Microsoft Entra access token. Waiting for an available pooled connection. Completing the SQL login. Executing the first command. When all these operations are reported through the same application method or log entry, it can look as though Azure SQL took thirty seconds to accept the connection. In reality, only part of that time may have been spent connecting to the database. In one anonymized support scenario, the application experienced problems mainly on its first connection. Network tests were successful and no corresponding SQL connection failure was identified. The investigation eventually showed that access-token acquisition was consuming a significant part of the available time. Increasing the SQL timeout or changing the firewall would not have addressed the real delay. Check 1: Capture the complete error and the exact time A screenshot containing only “Connection Timeout Expired” is rarely enough. Capture: The complete exception and inner exception. The operation being performed. The driver and version. The authentication method. The exact timestamp in UTC. Whether the issue affects every connection or only some of them. The wording around the timeout matters. For example, a timeout while obtaining a connection from the pool points toward the application’s pooling and concurrency behavior. A pre-login or TLS error belongs to a different investigation. A command timeout after the connection was established is usually a query-performance problem rather than a connection problem. Check 2: Measure the application timeline The application should record important operations separately. A simple timeline can completely change the investigation: 10:14:20.100 Token acquisition started 10:14:28.400 Token acquired 10:14:28.405 SQL connection started 10:14:29.050 SQL connection established The complete operation took almost nine seconds, but Azure SQL connection establishment took less than one second. Useful measurements include: Token-acquisition duration. Time waiting for a pooled connection. SQL connection-open duration. SQL command duration. Number of retry attempts. Applications using Microsoft Entra authentication must obtain an access token before authenticating to Azure SQL. Measuring that operation separately helps distinguish an identity delay from a database connectivity problem. This is particularly useful when the issue appears: On the first connection after startup. After a token expires. Only with Managed Identity or Workload Identity. Intermittently, while SQL authentication connections remain unaffected. Check 3: Test from the application environment A successful connection from a laptop does not validate the path used by an application running in: Azure App Service. Azure Functions. Azure Kubernetes Service. A virtual machine. An on-premises application server. A container or integration runtime. The laptop and the application may use different DNS servers, routes, firewalls, proxies and identities. Connectivity and DNS tests should therefore be performed from the environment that is actually failing. This becomes especially important when Private Endpoint is used. The application should continue connecting with: <server>.database.windows.net It should not use the Private Endpoint IP address or the privatelink.database.windows.net hostname directly. Direct login attempts using the private IP or the private-link FQDN fail; the normal logical-server FQDN must remain in the connection string. From the affected environment, confirm that: The expected DNS server answers the request. The server FQDN resolves to the expected private IP. The Private Endpoint connection is approved. The Private DNS zone is linked correctly. The resolved address is reachable through the intended route. A test from an unrelated machine is still useful for comparison, but it does not prove that the application path is healthy. Observed symptom Likely investigation area Timeout while obtaining a connection from the pool Application connection pooling Server name cannot be resolved DNS TCP connection to the endpoint cannot be established Network path, firewall or routing Error during the pre-login handshake TLS, driver, network interruption or pre-login processing Authentication or access-token error Microsoft Entra authentication, identity or token acquisition Timeout during the post-login phase Login completion, session initialization or server-side processing Execution or command timeout after connecting Query execution and database performance Avoid changing several things at once During a production incident, it is tempting to: Increase the timeout. Add firewall rules. Change the connection policy. Upgrade the driver. Restart the application. Clear connection pools. Applying several changes together makes it difficult to determine which one helped, and some may only hide the symptom. A better approach is to define one hypothesis: We believe DNS in the application environment is resolving the public endpoint instead of the Private Endpoint. Then define: The evidence supporting the hypothesis. One controlled change. The expected result. How the result will be measured. How the change will be reverted. Azure SQL supports Proxy and Redirect connection policies, which determine how traffic flows after reaching the Azure SQL gateway. The policy is configured for the logical server, so it should be verified before making firewall assumptions or changes. What should we collect before opening a support request? A small but precise evidence package can avoid several rounds of questions: Complete error and inner exception. Exact UTC timestamps. Application platform and location. Public or Private Endpoint. Server FQDN used by the application. Driver and version. Authentication method. Token, pool, connection and command durations. DNS result from the affected environment. Whether the issue is constant, intermittent or limited to the first connection. Recent application, network, identity or configuration changes.
After a week of heavy use, Microsoft 365 Copilot is creating more work than it saves
I am posting this publicly because I want to know whether other Microsoft 365 Copilot users are experiencing similar issues. Over the last week, Copilot has repeatedly created more work instead of reducing it. The recurring issues include: Failure to consistently use information that already exists within authorized Microsoft 365 content. Incomplete deliverables that require multiple rounds of prompting and manual assembly. Loss of context during longer conversations. Conversations becoming unresponsive with no practical recovery path. Assumptions presented as if they were verified facts. Deliverables requiring manual validation before they can actually be used. A recent example perfectly summarizes the problem. While helping me prepare Microsoft feedback, Copilot generated content that exceeded the destination character limit multiple times, even after being told the limit had already been exceeded. I repeatedly had to paste the content, discover the failure myself, return to Copilot, and request another correction. The user became the validator because the AI did not validate its own output before presenting it as complete. The larger concern is that this pattern appears across many workflows. The experience often looks like this: Request submitted. Incomplete answer returned. Missing information identified. Additional prompting required. Information is finally found. Consolidation requested. Additional omissions discovered. User assembles the final product manually. That is not productivity improvement. That is transferring research, validation, correction, consolidation, and quality assurance back to the user. I would appreciate input from other enterprise users: Are you experiencing similar issues? Have you found effective workarounds? Has Microsoft discussed planned improvements around context retention, workflow continuity, conversation recovery, enterprise grounding, response completeness, and validation? I have already submitted formal feedback through the Microsoft Feedback Portal and welcome discussion from users and Microsoft representatives.Moving mailboxes? Make sure your Deleted Mailbox Retention is not set to 0.
I wanted to bring to light a specific issue that may occur during mailbox moves in complex environments with multiple Active Directory Sites and multiple Exchange servers. There are several other settings which must be in place in order for this issue to present itself. First, here are the settings which need to be in place: 1. On both the Source and Target mailbox stores, set Deleted Mailbox Retention to 0 days. 2. Note what the Online Maintenance schedule is set to on both stores. The moves need to be scheduled to coincide with Online Maintenance on the Target mailbox store. *Note - for the purposes of my testing, I set Online Maintenance to run Always for my databases. 3. There must be multiple Active Directory Sites so as to introduce AD replication latency (Inter-Site connectors can only replicate every 15 minutes), and there need to be Exchange servers in these different AD sites (or Exchange must be configured to statically point to the GC of the other site). 4. Enable Diagnostics Logging under MSExchangeIS\Mailbox, and set the category General to Maximum (only minimum is necessary though). This is necessary in order to log Online Maintenance events. Some background here: one of the tasks performed by Online Maintenance is to identify mailboxes that are past the retention date and to delete them. As part of this task, it will also run the Cleanup Agent, which is the task that identifies orphaned/reconnected mailboxes. If you recall, in Exchange 2000 and 2003, if you delete a mailbox, it is not immediately deleted, nor is it marked as disconnected. If a mailbox is orphaned (no user connected to it), it gets marked as disconnected; if it is disconnected and past the retention date, it gets deleted. For more information on the tasks run during Online maintenance, please see the following link: http://technet.microsoft.com/en-us/library/aa996226(EXCHG.65).aspx During a mailbox move, the destination mailbox will be created so that data can be copied to it. This destination mailbox is not yet associated with a user account though. This process of associating with the user account does not happen until the very end of the mailbox move and all content has been copied to the destination mailbox. During the final step of the move, the user attributes are updated to point to the new server (if applicable) and new database. This process of updating attributes is what associates the destination mailbox with the user account. If you manually run the Cleanup Agent on the destination mailbox store during a move, you will find that the destination mailbox will show up as a disconnected mailbox. If you then run the Cleanup Agent again right after the move completes, you will find that in some cases the destination mailbox will also be purged. This can cause problems, because when a move is successful, the source mailbox is removed as well. If the Cleanup Agent is run from another Exchange server that is pointing at a different Active Directory Site, and the Exchange attributes (homeMDB, homeMTA, msExchHomeServerName) have not yet been updated, the Cleanup Agent will detect that this mailbox is not attached to a user account, and that it is past the retention date; and therefore, the mailbox will be deleted. You should see the following events indicating that this is occurring: Event 9533 The user account for "user" does not exist in the directory or is not enabled for Exchange mail. This mailbox will be removed from the mailbox store "database" in 0 days. Following that, you will see: Event 9535 Cleanup of deleted mailboxes that are past the retention date is finished on database "database" The first time I saw this event, the mailbox was not deleted. Then we have round 2, a few minutes later: Event 9531 Starting cleanup of deleted mailboxes that are past the retention date on database "database" Event 9535 Cleanup of deleted mailboxes that are past the retention date is finished on database "database" 1 deleted mailboxes have been removed Event 9532 The user account "user" does not exist in the directory or is not enabled for Exchange mail. This mailbox has been removed from the mailbox store "database" There are two ways to prevent this from happening: Make sure that Deleted Mailbox Retention is set to a non-zero value. Configure the Online Maintenance interval so that it does not overlap with your scheduled mailbox moves. Alternatively, set Online Maintenance to not run on days when you will be scheduling moves. If you have encountered a situation similar to this, we want to hear from you! Please post a comment. - Ben WinzenzAre ghosts modifying distribution groups in your mixed-mode environment?
We've seen a few issues recently where members of DGs (Distribution Groups) in mixed-mode Exchange 200x and 5.5 seem to randomly and mysteriously disappear. We thought we'd share one known root-cause and also show you how to prevent the problem while doing your migration, if for whatever reason you are still running Exchange 5.5 =). One easy way to prevent this problem (and a few others) is to ALWAYS use the Exchange 2003 post SP1 cross-site mailbox migration wizard if you ever have to move mailboxes in a mixed-mode environment. With that said, typically the problem occurs when you use a directory export/import to move mailboxes between Exchange 5.5 sites. For example, if you have two Exchange 5.5 sites Site S (Source) and Site D (Destination) and you would like to move all the mailboxes in Site S to Site D you might perform the following steps. (When we refer to a DL we mean a Distribution List on the Exchange 5.5 side and when we refer to DG we mean a Distribution Group on the Active Directory side) Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source Exchange 5.5 server in Site S Delete the source mailboxes in Site S Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also wait for the Active Directory Account to become mailbox-disabled. Do a directory import of the mailbox information in Site D to recreate the mailboxes. Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site The problem occurs after step 4. The following key points should help you understand why. Replication between Exchange 5.5 sites is governed by USN-Changed values. Any changes made to an object in a directory in one site only replicate to other sites if that object's USN-Changed value is higher than the corresponding value in some other site. For the special case of a mailbox deletion, you would expect the USN-Changed value for any DL that the mailbox is a member of to increment after the mailbox deletion. This is, however, not necessary because when you delete a mailbox from its 'home' site, the member property of the DL changes and the read-only copy of the mailbox in all the other sites gets deleted. When the read-only copy is deleted in all the other sites the DL membership is updated as well. The salient point is without incrementing a DL's USN-Changed, all the necessary changes for the sites to be in-sync are properly accounted for. This works well for a pure Exchange 5.5 environment but creates a problem for a mixed-mode one with an ADC (Active Directory Connector) in the mix. As we know, the ADC compares the msExchServer2HighestUSN value on the RCA (Recipient Connection Agreement) to the USN-Changed value of an object in the Exchange 5.5 directory to determine whether the Exchange 5.5 object should be replicated to the AD. If the USN-Changed on an object is greater than the msExchServer2HighestUSN on the RCA, the object has been changed in the Exchange 5.5 directory and needs to be updated in the AD. If msExchServer2HighestUSN is greater than or equal to USN-Changed, no changes have occurred on the 5.5 object that need to be updated (replicated to) on the AD side. See the following knowledge base article for further details 253840. In this situation, since the DLs' USN-Changed isn't incremented in the 5.5 directory when you delete the mailboxes, the corresponding DG (Distribution Group) membership in the AD isn't updated. If you later make changes that increment the USN-Changed on the DL, the entire object (including the earlier deletions) is replicated to the AD side and so some members seem to randomly disappear from the DG's members list. While replication in Exchange 5.5 is object-based and replication in the AD is attribute-based, Exchange 5.5 to AD replication is still object-based (think lowest common denominator). The solution to this problem is to force the USN-Changed on the DL to increment after performing the deletions in step 3. A DL's USN-changed increments under the following scenarios: If you use the Exchange 5.5 Administrator program to open the DL's properties, modify any value and click Apply or OK (Or if you modify the DL's properties by doing an directory export/import with the standard header fields) If you use the Exchange 5.5 Administrator program to open a mailbox's properties and remove a DL from the list of DLs that the mailbox is a member of If the DL is updated by DRC or ADC replication changes from other 5.5 sites or from the AD respectively Again, a DL's USN-Changed does not increment when you use the Exchange 5.5 administrator program to delete a mailbox from the DLs membership. To force the USN-Changed value on the DL to increment you need to make a 'dummy' change that falls under a, b or c after step 3. Our new steps to ensure we avoid the problem would therefore be: Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source 5.5 server in Site S Delete the source mailboxes in Site S Use the Exchange 5.5 Administrator program to modify the "notes" field on all the DLs that contained the deleted mailboxes to force an increment of USN-Changed value. This step is critical Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also trigger RCA replication and make sure that the 'member of' list for the AD user accounts that correspond to the deleted mailboxes is empty (except built-in groups such as Domain Users etc) Do a directory import of the mailbox information in Site D to recreate the mailboxes Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site. Add the migrated mailboxes to the corresponding DLs manually using the Exchange 5.5 Administrator program. This step may not seem necessary but it is. Usually an administrator may notice that the member list is still present on the AD after performing the previous steps and therefore assume that nothing more needs to be done on the Exchange 5.5 side. Later when some other change increments the USN-Changed the deletions replicate to the AD and members seem to randomly disappear from DGs. Everything should work fine and dandy at this point and you needn't worry about 'ghosts' modifying your DGs! - Jasper Kuria and William YangI'll have some transaction log files for breakfast day
With viruses spreading quick out there today, we had several cases where Exchange transaction logs got either deleted, quarantined or "cured" by file-level anti-virus software that is running on Exchange servers... the result is a bad thing... stores down, transaction logs missing. In some cases the only thing you can do is go back to the last backup if one that is good is available. Otherwise - you are looking at possible repair (= data loss) + Isinteg (maybe 2-3 times) + mandatory offline defrag = a lot of time that is lost :( Please, do not let Exchange directories be scanned by file-level AV. Not "on-demand" one, not the memory resident one. Have Exchange directories excluded, the M: drive excluded, and actually - exclude specifically .log, .edb and .stm files too just to be extra careful. To be more specific, excluding the following on Exchange server is a GREAT idea: Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder. You can verify the locations by pulling up properties of your databases in ESM and checking the Database tab. Exchange MTA files in the Exchsrvr\Mtadata folder. Additional log files such as the Exchsrvr\server_name.log file. The Exchsrvr\Mailroot virtual server folder. The working folder that's used to store streaming temporary files used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location. The temporary folder that is used in conjunction with offline maintenance utilities such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure where you run the file from when you run the utility. Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder. Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder. The Exchange 2000 Server drive M. More appropriate reading: 328841 XADM: Exchange and Antivirus Software 823166 Overview of Exchange Server 2003 and Antivirus Software Nino BilicRegistry Inventory in Microsoft Intune: Verifying What’s on Your Devices
By: Madison Cooks, Product Manager | Microsoft Intune IT admins need a reliable way to confirm how Windows devices are configured, especially when troubleshooting, validating compliance, or investigating security posture. Policy assignment alone doesn’t always show what’s present on the device and getting registry visibility at scale has often required custom discovery or remediation scripts that take time to build, test, and maintain. With Microsoft Intune’s July (2607) release, device inventory will include Windows registry data, helping IT admins verify a device’s actual configuration, not just the policy assigned. With a new Device inventory property for registry keys, you define the keys you care about in the properties catalog, and Intune collects them for you. There’s no collection logic to build or keep running. This makes registry-based configuration checks easier to operationalize across managed Windows devices, so teams can spend less time maintaining scripts and more time acting on the data. Figure 1: Microsoft Intune device inventory profile creation screen showing the Properties picker with the Registry category selected for inventory data collection. What registry data you collect Registry data collection is configured through the existing properties catalog. For each entry, provide a registry key path and, when needed, a value name. For every targeted device, the device agent attempts collection and reports: Registry key path Value name Value type Value data Microsoft Intune device inventory profile configuration page showing registry key collection settings, including registry path, collection pattern options, and value name fields. The initial release supports the following collection patterns designed for common admin scenarios that use HKEY_LOCAL_MACHINE (HKLM) paths. Single value Specify a registry path and value name to collect one value from that path. For example, collect Secure Boot certificate servicing status from HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot by using values such as UEFICA2023Status, UEFICA2023Error, or UEFICA2023ErrorEvent. All values under a path, non-recursive Specify a registry path to collect all values directly under that path. This pattern doesn't include subkeys. For example, collect values directly under a Windows Update configuration path to help validate expected settings. Same value across subkeys Specify a base registry key path and a value name to collect that value from each immediate subkey. For example, collect DHCP status across network interface subkeys under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. Where registry inventory data appears After collection, registry inventory data will be available in Device inventory at initial release. We’ll expand access to registry data in the coming months, including support in additional reporting and exploration experiences. Microsoft Intune Device Inventory page displaying collected Windows registry data for a device, including registry key paths, values, collection status, and timestamps. This makes registry data available alongside other inventory signals, so admins can use familiar tools to investigate configuration, validate device state, and support troubleshooting without building separate collection scripts. How admins use this You can collect registry data and view it per device in Device inventory - a verified record of each endpoint’s actual configuration and a key source of settings data on each endpoint. This helps answer questions like: Is a setting actually enabled on the device? Which app, version, or configuration is installed? Did a policy apply correctly? Why is this device behaving differently from the rest? Registry data collection in Device inventory is included with Microsoft Intune Plan 1. Collection results and limits If a registry value exists but doesn’t contain data, collection succeeds and the value appears as empty. If the registry path or value name doesn’t exist on a device, that device reports Not found for the collection result. Collection continues for all other devices, so one missing value won’t block results from devices where the value exists. Registry inventory includes safeguards to keep collection focused and manageable. Each collected registry value is capped at 6 KB, and each device can collect up to 100 registry keys. If a value or device exceeds these limits, collection skips the excess data and reports the applicable result for that device. These limits help manage data volume, maintain service performance, and reduce the risk of over-collection. Registry inventory is designed for configuration visibility and troubleshooting, not for collecting sensitive or confidential data. Built-in heuristic detection helps identify and prevent ingestion of values that may contain secrets, credentials, authentication tokens, certificates, private keys, connection strings, or other data that could grant access if exposed. If a value is flagged as potentially sensitive, it isn’t collected. Collection is limited to HKEY_LOCAL_MACHINE (HKLM) paths. This keeps inventory focused on device-level configuration and avoids user-specific registry contexts. Summary Registry inventory in Microsoft Intune helps admins collect Windows registry data in a native, declarative way. Instead of maintaining custom scripts for common inventory scenarios, admins can configure registry collection in the properties catalog and query the results through familiar Intune reporting experiences. Use registry inventory for configuration visibility and troubleshooting across managed Windows devices. As you plan your collection strategy, focus on device-level HKLM data, avoid sensitive values, and remember collection limits to keep inventory targeted and manageable. If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.Copilot in Word can't read chat attachments; Word for web file picker shows “no token obtained”
Summary of the issue I am seeing a persistent failure with Copilot attachments specifically inside Microsoft Word. Copilot in Word desktop and Word for the web can recognize an uploaded chat attachment by filename or OneDrive URL, but it cannot read the file contents. It reports the uploaded file as empty, corrupted, or in a format it cannot process. The same files are successfully read by standalone Microsoft 365 Copilot Chat using the same Microsoft account, and file uploads also work in Excel Copilot and PowerPoint Copilot. Failure started 10 days ago, with no obvious changes in settings on my end. The most useful diagnostic clue so far is that Word for the web’s Copilot attachment/file-picker path has also failed before any file was selected, showing “Something went wrong, please try again or refresh the page, no token obtained.” In Chrome, Word for the web produced a SharePoint-style error page with a correlation ID. This makes the issue look less like a bad file or local Word installation problem and more like a Word Copilot attachment-picker, OneDrive/SharePoint authorization-token, or file-handoff problem. Environment and scope Windows 11, Pro. Microsoft Word desktop: issue reproduced after updating Office and Windows. Word for the web: issue reproduced in Edge, Edge InPrivate, and Chrome. Standalone Microsoft 365 Copilot Chat / copilot.microsoft.com / m365.cloud.microsoft/chat: uploaded files can be read successfully with the same Microsoft account. Excel Copilot and PowerPoint Copilot: uploaded files work. OneDrive in Chrome: upload/download and file access work normally with the same account. Same Microsoft account used throughout. File types tested include tiny TXT files, PDFs, and DOCX files, including a complex DOCX. Copilot in Word can read the active Word document normally; the failure is limited to files uploaded as Copilot chat attachments inside Word. Observed behavior In Word desktop, Copilot chat accepts or recognizes the attachment metadata, including filename and sometimes a OneDrive URL, but when asked to read or summarize the file it says the file appears to be empty, corrupted, or in a format it cannot process. This happens even with a very small TXT test file. In Word for the web, the same general failure occurs. In one clean test, I created a brand-new blank Word document in Word for the web, opened Copilot, attached a tiny TXT file, and asked what the uploaded TXT file said. Copilot responded: “The uploaded file ingestion_test_731_1915.txt appears to be empty, corrupted, or in a format I can’t process, so I can’t read any text from it.” In another Word for the web test, clicking Copilot’s “+” attachment button and choosing either “My Files” or “Recent” opened a mostly blank window saying: “Something went wrong, please try again or refresh the page, no token obtained.” This occurred before any file was selected. In Chrome, Word for the web produced this error when trying to use the Copilot attachment flow: “Sorry, something went wrong. An unexpected error has occurred. Technical Details: Troubleshoot issues with Microsoft SharePoint Foundation.” The error included Correlation ID 64062ea2-3083-8000-a0f7-fbf4f6bb617d and Date/Time 8/4/2026 12:21:38 PM. Evidence matrix Test Result Standalone Microsoft 365 Copilot Chat / copilot.microsoft.com DOCX, PDF, and TXT uploads can be read successfully with the same account. OneDrive in Chrome Upload, download, and file access work normally. Excel Copilot Uploaded files work. PowerPoint Copilot Uploaded files work. Word desktop Copilot Attachments are recognized but reported as empty, corrupted, or unprocessable. Word for the web in Edge/InPrivate Tiny TXT attachment reported as empty, corrupted, or unprocessable. Word for the web attachment picker “No token obtained” message before file selection. Word for the web in Chrome SharePoint Foundation-style error with correlation ID 64062ea2-3083-8000-a0f7-fbf4f6bb617d. Word Copilot reading the active document Works normally. Troubleshooting already tried Updated Microsoft Office / Microsoft 365 desktop apps. Updated Windows. Restarted Word multiple times. Restarted the computer multiple times. Signed out and signed back in. Confirmed that the same Microsoft account is being used; there is only one Microsoft account involved. Toggled connected experiences off and back on, including restarts between changes. Started Word in Safe Mode. In Safe Mode, Copilot chat opened but did not activate properly; the Copilot pane appeared to cycle in the background and sub-windows were blank/unusable. Tested with a brand-new blank Word document in Word for the web. Tested in Edge, Edge InPrivate, and Chrome. Tested with very small TXT files as well as PDF and DOCX files. Confirmed OneDrive itself works normally in Chrome by uploading and accessing files successfully. Confirmed standalone Copilot and Excel/PowerPoint Copilot can process uploaded files successfully. Why this does not look like a local file or browser problem The same uploaded files work in standalone Microsoft 365 Copilot Chat, and OneDrive upload/download works normally. The issue also reproduces across Word desktop and Word for the web, across multiple browsers, and with a brand-new blank Word document. Because Word Copilot can read the active document but cannot acquire or process uploaded chat attachments, the failure appears isolated to the Word-integrated Copilot attachment picker, authorization-token acquisition, or OneDrive/SharePoint file-handoff path. Most likely failure area My current working theory is that Word-integrated Copilot is failing to obtain or pass the required SharePoint/OneDrive authorization token for Copilot chat attachments. The “no token obtained” message and the SharePoint Foundation correlation ID point toward the file-picker or backend handoff path rather than file contents. It may be account-specific, feature-flight/routing-specific, or a Microsoft-side regression affecting Word Copilot attachment handling. Request for help Has anyone seen Word Copilot attachments fail in this way while standalone Copilot, OneDrive, Excel Copilot, and PowerPoint Copilot all still work? Are there known Word Copilot attachment-picker, OneDrive/SharePoint token, or feature-routing issues that can affect only Word-integrated Copilot? If Microsoft support or engineering can trace backend logs, the most relevant correlation ID I have is 64062ea2-3083-8000-a0f7-fbf4f6bb617d from 8/4/2026 at 12:21:38 PM in Word for the web in Chrome. I would especially appreciate suggestions for anything beyond the standard local troubleshooting already tried. At this point, the pattern suggests the next useful step is probably backend investigation of the Word Copilot attachment/file-picker authorization flow rather than more file-format testing or local repair.
