Blocked out of my email
Cannot sign in to email after travelling. I have sent off over 10 account recovery forms with no replies back. My old mobile number is linked to the account so I cannot get a text verification, I also rang the old number and they are not willing to help. And it is so hard to speak to a real person from Microsoft to fix this, I managed to get an agent once and they tell me to fill out another form which clearly is getting me nowhere.Zoom further in more Microsoft Access views
Zoom from 10% to 1000% Supported Access views can now be zoomed anywhere from 10% to 1000%, expanding the previous range of 50% to 500%. New 10%, 25%, and 1000% choices are available in the Zoom menu, and the status bar slider supports the full range. The expanded range is also available when configuring the default zoom level for a database. Zoom more types of forms Zoom is now supported in both continuous forms and popup forms. In a continuous form, zoom scales the repeating records and their controls together, making it easier to read individual records or see more records at once. Embedded continuous forms also scale with their parent form, keeping nested content visually consistent. Popup forms can be zoomed without changing their underlying design. Because popup forms do not use the standard status bar zoom control, you can zoom them with Ctrl+mouse wheel or the zoom keyboard shortcuts. Zoom reports in Report View Zoom is now available for reports in Report View, bringing reports in line with forms, tables, and queries. You can enlarge a report to inspect individual values or zoom out for a broader view of its layout and data. Reports displayed inside forms also scale with their parent, providing a more consistent experience for databases with nested forms and reports. Choose how you zoom Depending on the type of object you’re viewing, you can: Select a percentage from the Zoom menu on the ribbon. Drag the zoom slider on the status bar. Hold Ctrl and scroll the mouse wheel. Press Ctrl+Alt+Plus or Ctrl+Alt+Minus to zoom in or out. Press Ctrl+Alt+0 to return to 100%. With a wider range and support for reports, popup forms, continuous forms, and nested content, it’s now easier to tailor your Access workspace to the task at hand—whether that means focusing on the details or taking in the bigger picture.
Print to PDF and crashing issue - Access Version 2607 and 2608
Multiple customers are reporting crashing and print to pdf issues after updateing to Access version 2607 and 2608. Versions with the issue: Version 2607 (Build 16.0.20228.20190), Version 2608 (Build 16.0.20326.20072), and Version 2608 (Build 16.0.20326.20100) Working version is version 2606 (Build 16.0.20131.20154), rolling back to this will resolve these issues. Crashing (Build 16.0.20326.20022) Some users reported that crashes occur shortly after opening the Access application. Here is the event log error. Faulting application name: msaccess.exe, version: 16.0.20326.20100, time stamp: 0x6a83d187 Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000409 Fault offset: 0x00007ffb274a628f Faulting process id: 0x5BF8 Faulting application start time: 0x1DD2FF382F4BC5A Faulting application path: C:\Program Files\Microsoft Office\root\Office16\msaccess.exe Faulting module path: unknown Report Id: a6329f20-3c01-439f-a152-a7cdb6ef74b4 Faulting package full name: Faulting package-relative application ID: PDF not formatting correctly (Build 16.0.20228.20190 and Build 16.0.20326.20072) Exporting the Access report to PDF will cause the following issues. When exporting a multi-page report as PDF, the second page displays at a quarter of its original size. Some users experience the right margin being slightly larger, causing the right size to be cut off. Some text on the report are changed to a different font type and size after exporting PDF. Form textbox, label and buttons display properties are changed after previewing a report (Replicated on Build 16.0.20228.20190) After closing the print preview of a report, the Access form's textbox, label and buttons are not displayed correctly. Some text are not visible, background color seems to have changed, font type are different as well. The Access application is required to be closed and reopen to fix the issue.ControlTipText no longer supports multiline text / wrapping in Access 2608
I’ve noticed what appears to be a recent regression in Access concerning the ControlTipText property. Previously, embedded line breaks such as: .ControlTipText = "Line 1" & vbCrLf & "Line 2" & vbCrLf & "Line 3" displayed as a multiline tooltip. In current builds, the vbCrLf is still present in the property value but is ignored when the tooltip is displayed, so the text appears on a single line. I also tested automatic wrapping with: .ControlTipText = String(70, "A") & " " & _ String(70, "B") & " " & _ String(70, "C") and the tooltip does not wrap at all; it simply continues horizontally off the right-hand side of the screen. I confirmed that the line-break characters are still stored by using Replace(ControlTipText, vbCrLf, "<CRLF>"), which finds and replaces them correctly. I also tried vbLf and Chr(13) & Chr(10) with the same result. The issue is present in: Microsoft Access for Microsoft 365 Version 2608 Build 16.0.20326.20132 64-bit It was also present before updating to this build. This looks as though the tooltip itself is no longer being configured for multiline/wrapped display, rather than Access altering the contents of the ControlTipText property. Has anyone else seen this, or can Microsoft confirm whether it is a known issue?August 2026 RDP font display glitch
In the last days, we have received two independent reports of font display problems in our MS Access based application. The symptoms are as follows: Some labels or text boxes are shown in a legacy system font instead of the font specified in the control (Segoe UI). Also, the label/text box is shown with a white background instead of transparent. Moving the Access window "fixes" the glitch. It happens at seemingly random places in our application at seemingly random times. Both reports have in common that the Access application is running inside an RDP session. In report 1, a work-from-home user used Remote Desktop to connect to their office Windows 11 PC, and, in report 2, a user executed the application on a Windows Terminal Server. Here are a few screenshots to illustrate the problem. The left side is the glitch, the right side is how it is supposed to look. The first row shows labels, the second row text boxes in a continuous subform. Report 1 is 16.0.20228.20186, 32 bit, M365 SAEC. Report 2 is 16.0.14334.20848, 32 bit, Office 2021 LTSC. Is this a known issue, or shall we continue to collect data about this glitch? Unfortunately, we haven't found a reliable way to reproduce it, so our ability to test it with different versions is limited.Who Can Access What? Designing RBAC and Identity in Azure
Who should be allowed to access an Azure resource? Azure makes it easy to create resources. The harder question comes afterwards: who should be allowed to access them? A Function App may need to read secrets from Key Vault. A Logic App may need to call APIs through API Management. A developer may need to deploy to Dev but have no access to Production. A CI/CD pipeline may need to deploy infrastructure without becoming an Owner of the entire subscription. This is where Azure Role-Based Access Control (RBAC) and Managed Identity become critical. In this article, I look at how to design access around people, applications and deployment pipelines, while keeping permissions as narrow as practical. The article covers: Azure RBAC and access scopes Least-privilege access Managed Identities Developer vs Production access boundaries Application identities CI/CD deployment permissions RBAC vs API authentication Privileged access and PIM Common RBAC design mistakes One of the key principles is simple: Give an identity only the permissions it actually needs. For example, if a Function App only needs to read secrets from Key Vault, giving it Contributor access to the entire Resource Group solves the problem with a much broader permission than necessary. Good RBAC design is not about assigning more permissions. It is about understanding: Who needs access? Why do they need it? What exactly do they need to do? At what scope should access be granted? How can that access be managed securely over time? I would be interested to hear how others approach RBAC and identity design in enterprise Azure environments. Full article: https://www.linkedin.com/pulse/who-can-access-what-designing-rbac-identity-azure-chethan-raj-ud6gc/
Access 2608 Build 20326: Line controls disappear in Print Preview
I believe there may be a regression in Microsoft Access Build 16.0.20326.20034 (64-bit) affecting Line controls in reports. I can reproduce the problem even with a completely new blank MDB database, so it does not appear to be related to an existing application. Steps to reproduce: 1.Start Microsoft Access 64-bit Build 16.0.20326.20034. 2.Create a new blank MDB database. 3.Create a new report in Design View. 4.Add a Line control to the Detail section. 5.Add a Rectangle control to the same section. 6.No VBA code or special event handling is required. 7.Select Microsoft Print to PDF as the printer. 8.Open Print Preview. Actual result: The Rectangle control is displayed correctly, but the Line control disappears in Print Preview. The problem is not specific to a particular printer. We have reproduced it with multiple printers. Expected result: Both the Line and Rectangle controls should appear in Print Preview and in the printed output. Workaround: Rolling Microsoft Access back to an earlier build immediately resolves the problem. The same MDB file and the same report then display and print the Line control correctly. We have also reproduced the issue with Build 16.0.20326.20044 (64-bit). Has anyone else been able to reproduce this with Version 2608 / Build 20326?
