New family storage limits from 6 TB to only 2 TB
I’m a little freaked out what I’m going to do with my entire family’s storage. Right now each of my kids and wife use nearly 1 TB for a total of nearly 5 TB. Since they are reducing this to a new “shared 2 TB” rather than 1 TB each, I am stuck either paying more money or finding a new solution. I am paid up into 2028. It seems terrible that I have paid for this and it is being taken away.
Excel Nested Arrays: Find the Nesting Depth of Uniform and Ragged Arrays ARRDEPTH() & ISRAGGED()
Hey everyone! I’ve been diving deep into Excel’s new nested arrays features lately, and I absolutely love the flexibility they bring to data structuring. However, managing them can get a bit tricky, so I figured I’d build some specialized tools to handle them seamlessly. Public Interfaces & Arguments =ISRAGGED(array) Argument Description Default Behavior array Target nested structure to validate. Required =ARRDEPTH(array, [is_ragged]) Argument Description Default Behavior array Target nested structure to measure. Required [is_ragged] TRUE: Scans all branches for the deepest path. FALSE: Speed test on the first path only. FALSE (Omitted) TL;DR (What makes it tick): Function Name Type What It Does ARRDEPTH Public UI Returns nesting depth. Supports deep checking or fast linear testing. ISRAGGED Public UI Structural validator. Returns TRUE if array branches have uneven nesting. ANALYZE_NESTING Hidden Core Engine Multi-process recursive parser that tracks tree structure geometries. LINEARDEPTH Hidden Utility High-speed depth checker that evaluates the first element path exclusively. You can get both functions from my GitHub Gist: https://gist.github.com/Medohh2120/9cdf939036942c9672c57ccd6de696d3Build bigger forms in Microsoft Access
For many years, Microsoft Access forms were limited to 22 inches in width and in the height of an individual section. That size works well for many solutions, but it can become restrictive when you are building a wide dashboard, arranging many controls, designing for a large display, or creating a detailed data entry workflow. With Big Forms, a form can be up to 2,000 inches wide, and each individual vertical dimension can be up to 2,000 inches. The combined height of all sections and their Design View section headers can be up to 2,100 inches. Continue using the familiar Access design surface, property sheet, rulers, and scrollbars, with substantially more space available when your solution needs it. More room for the solutions you already build Wider layouts Extend forms up to 2,000 inches wide for dashboards with more fields, controls, and content displayed next to each other. Taller sections Use up to 2,000 inches for an individual vertical dimension and up to 2,100 inches across all sections. Familiar design tools Enter dimensions in the property sheet or resize controls directly on the design surface as you do today. How to create a bigger form Open your object in Design View. Open an existing form, or create a new one. Resize the design surface or a section. Drag an edge beyond 22 inches, or enter a Width or Height value of up to 2,000 inches in the property sheet. Position and size your controls. Move controls into the expanded area or set larger Left, Top, Width, and Height values. Save and reopen as usual. Access preserves the expanded dimensions when you save the form. No conversion required You do not need to recreate existing forms. Open the form in a supported version of Access and extend the layout only when you need additional space. Use Big Forms from VBA You can read and set expanded dimensions through the existing VBA Properties collection. Values are expressed in twips, with 1,440 twips in one inch. The 2,000 inch maximum is 2,880,000 twips. Public Sub ResizeCustomerOverview() Const TwipsPerInch As Long = 1440 DoCmd.OpenForm "CustomerOverview", acDesign With Forms("CustomerOverview") .Properties("Width").Value = 100 * TwipsPerInch .Section(acDetail).Properties("Height").Value = 50 * TwipsPerInch .Controls("Notes").Properties("Left").Value = 24 * TwipsPerInch .Controls("Notes").Properties("Width").Value = 60 * TwipsPerInch End With DoCmd.Save acForm, "CustomerOverview" End Sub No new property names are required. Use Properties("Left") , Properties("Top") , Properties("Width") , and Properties("Height") to work with the new larger limits. Why use the Properties collection? Typed VBA members such as Control.Left retain their legacy 16 bit contract for compatibility with existing code. On an expanded form, those typed members return a value limited to the 16 bit range. The Properties collection reads and writes the complete Big Forms value. Designed with compatibility in mind Backward compatibility is determined for each form. Access only uses the new saved form format when a form actually exceeds a legacy limit. Forms that remain within the previous limits continue to use the existing format, even when they are saved by a version of Access that supports Big Forms. When a form uses the expanded range, Access saves its full values in wider properties and marks that specific form as requiring Big Forms support. An earlier version of Access can still open the database and work with its other compatible objects. If someone tries to open the expanded form, Access displays a message explaining that the form requires a newer version. Compatibility without silent data loss Earlier versions do not truncate or reinterpret an expanded form. They stop before loading that form and show a clear compatibility message, while the rest of the database remains available. Sharing a database? Make sure everyone who needs to open an expanded form is using a supported Access build. This is especially important for shared front end databases and packaged Access applications. Availability Big Forms is rolling out on Current Channel, beginning with version 16.0.20430.20146. It is enabled for some customers now and is expected to reach everyone on Current Channel early next week. If you are on that build and do not yet see the expanded limits, check again in a few days. Availability Rolling out on Current Channel Version 16.0.20430.20146 or later Platform Microsoft Access for Windows To check your version, open Access and select File > Account > About Access. Try Big Forms and tell us what you think Use the expanded design surface with your forms, then share what works well and where you would like to see improvements. Share feedback about Access Feature availability and release timing can vary by update channel.
Excel pivot chart's secondary axis disappears after parameter in chart is filtered at slicer
Hi, A pivot chart on Sales (primary y axis) and Rate (secondary y axis) is plotted against time (X axis). Area parameter is part of the underlying dataset, but not plotted in same chart. When Area or Rate is filtered at respective slicer, the secondary y axis disappears i.e. pivot chart resets to having only primary y axis How may I keep the secondary y axis after filtering? Thank you.
Staff Email hacked Restored but not able to receive any emails
Could you please advise on the best way to restore emails for a staff member whose email account was recently compromised? I am the account administrator and am trying to recover any missing messages and verify mail flow. I have already used Message Trace, but I can't locate a test message I sent to the user. Any guidance on the appropriate recovery steps or troubleshooting recommendations would be greatly appreciated. Thanks
Unable to Open an Old OST File After Outlook Profile or Mailbox Changes
Hi everyone, I am looking for suggestions on handling an old OST file where the original Outlook profile or mailbox is no longer available. The situation is that an OST file contains important mailbox data, but Outlook cannot open it normally after changes to the user account or profile. This can happen after a Microsoft 365 mailbox change, Exchange migration, user account removal, or when an OST file becomes damaged. Since OST files are linked to the Outlook profile and mailbox that created them, simply moving the file to another system does not always make the data accessible. Before attempting any recovery approach, I would like to understand the recommended steps: Is there any Microsoft-recommended method to access an orphaned OST file? What checks should be performed before trying to recover data from the OST? How do administrators usually handle old OST files when the original mailbox is no longer available? What is the best way to validate recovered mailbox data? I would appreciate feedback from anyone who has handled similar Outlook OST recovery scenarios after Microsoft 365 or Exchange changes.
MS Outlook 2024 LTSC automatically gets closed and later not getting open
In Outlook 2024 LTSC, the application suddenly stops and closed automatically. Later troubleshooting, it is observed that it doesn't even open in safe mode. Tried to create a new profile where it is not able to search the user from exchange and automatically redirect to Microsoft 365 login page whereas our mail server works in exchange mode. Even after reinstalling the MS office 2024, it is not able to search the user and redirects to Microsoft 365 login page. What is the issue and resolution.
Excel can still use legacy “Move and Size with Cells” checkboxes — but can no longer create them
Excel Can Still Use “Move and Size with Cells” Form Checkboxes — But It Can No Longer Create Them A reproducible Excel compatibility regression hiding inside legacy Form Controls For years, I have used Excel workbooks containing hundreds of Form Control checkboxes attached to product rows. These checkboxes behaved exactly as you would expect: - change the row height, and the checkbox stays inside that row; - filter the worksheet, and the checkbox disappears together with its product; - remove the filter, and the checkbox returns to the correct row; - no overlapping controls; - no “click one checkbox, activate another” behaviour. Recently, while rebuilding one of these workbooks in Excel 2024 LTSC, I discovered something very strange. The old checkboxes still work perfectly. But if I delete one and recreate it — even using the same VBA code that originally created the controls — Excel creates a different kind of placement behaviour. After a full day of controlled testing, XML inspection and A/B workbook comparison, the problem became clear: Excel can still read, display, save and execute legacy Form Control checkboxes using true “Move and size with cells” behaviour — but current Excel cannot recreate that same state for a newly created Form Control checkbox through the normal UI or VBA object model. That is not just inconvenient. For existing business workbooks, it is a serious backward-compatibility problem. The simple VBA code that used to work The original controls were created with ordinary Excel VBA: Set myCBX = wks.CheckBoxes.Add( _ Top:=cell.Top, _ Left:=cell.Left, _ Width:=cell.Width, _ Height:=cell.Height) Nothing exotic. No custom event engine. No ActiveX. No external add-in. Just a standard Excel Form Control checkbox positioned exactly over a cell. The workbook contains roughly 1,000 of these controls. The old ones still behave correctly today. The problem starts only after deleting them and creating new ones. What changes? In the Excel UI, the difference is immediately visible. For an original legacy checkbox: Format Control → Properties shows: Move and size with cells The option is selected, although it is greyed out. For a newly created checkbox in current Excel: Move but don’t size with cells is selected instead. That already suggests something changed internally. But the real evidence is inside the .xlsm package. The OOXML tells the story I created two controlled test workbooks: Workbook A Original legacy Form Control checkboxes that behave correctly. Workbook B The same workbook, but the checkboxes were deleted and recreated in current Excel using the original VBA logic. The internal OOXML differs. The working legacy controls contain placement information equivalent to: moveWithCells="1" sizeWithCells="1" and use genuine two-cell anchoring. The newly generated controls are instead stored using one-cell-style placement semantics, including: <xdr:twoCellAnchor editAs="oneCell"> The important part is not merely the XML syntax. The resulting behaviour is observably different. With the legacy control, both ends of the object are anchored to the worksheet grid. With the newly created control, Excel effectively preserves the control size while cells move underneath it. That distinction becomes disastrous when rows are resized, hidden or filtered. Why filtering exposes the problem Imagine a checkbox sitting on row 50. With the legacy behaviour: Checkbox ↔ Row 50 boundaries When row 50 changes size, the checkbox changes with it. If row 50 is filtered out, the control disappears with the row. When the row becomes visible again, the control is still exactly where it belongs. With the newly generated control, its dimensions are not tied to both cell boundaries in the same way. After repeated resizing and filtering, controls can begin to overlap. That leads to one of the worst possible spreadsheet UI failures: You click the checkbox you can see, but another checkbox receives the click. For a workbook containing hundreds or thousands of rows, this makes the controls unreliable. “Just use .Placement = xlMoveAndSize” That was the obvious first solution. Excel VBA defines: xlMoveAndSize as the placement mode where an object moves and resizes with cells. So I tested: myCBX.Placement = xlMoveAndSize and: myCBX.Placement = 1 I also tested placement through the corresponding Shape: ws.Shapes(myCBX.Name).Placement = xlMoveAndSize And through a ShapeRange. And through DrawingObjects. And even the commonly suggested workaround: Group controls → set Group.Placement = xlMoveAndSize → Ungroup None of these recreated the original internal state in Excel 2024 LTSC. The workbook continued to serialize the new controls differently. This matches long-standing Microsoft guidance that Form Control checkboxes do not normally support “Move and size with cells” as an editable option, while ActiveX checkboxes do. And yet — this is the important part — existing legacy Form Control checkboxes in real workbooks can still possess and use that state. The most revealing experiment I then modified the OOXML manually. I took the newly generated workbook and patched the checkbox placement metadata to match the working legacy controls: moveWithCells="1" sizeWithCells="1" with proper two-cell anchoring and without the one-cell override. Then I reopened the workbook in Excel 2024 LTSC. And it worked. Immediately. No custom VBA reposition engine. No ActiveX. No workaround running continuously. The same Excel installation that would not create this state through VBA had absolutely no problem: - reading it, - displaying it, - saving it, - resizing the controls with rows, - and filtering them correctly. That is the key finding. The Excel rendering and file engines still fully understand this checkbox state. The missing part is the supported creation path. So is this an unsupported feature or a compatibility regression? Microsoft has historically documented Form Control checkboxes as not supporting “Move and size with cells” in the normal UI. That makes the situation unusual. The issue is not simply: “Excel removed a documented checkbox feature.” The stronger and more accurate statement is: Excel supports a legacy Form Control state in existing workbooks, continues to execute it correctly, but no longer provides an ordinary supported mechanism to reproduce that same state for a replacement control. For users maintaining long-lived Excel systems, the difference is academic. If an old control is accidentally deleted, replacing it with an apparently identical Form Control changes the behaviour of the workbook. That is a backward-compatibility problem. Why not switch to ActiveX? ActiveX checkboxes support richer placement behaviour. But that creates another problem. Microsoft now disables ActiveX controls by default in Microsoft 365 and Office 2024 for security reasons. When ActiveX is disabled, users cannot create new ActiveX objects or interact with existing ones. So the official alternatives are hardly attractive: Legacy Form Controls Lightweight and reliable — but cannot reproduce this legacy placement state normally. ActiveX Supports more control behaviour — but is now a legacy security-sensitive technology disabled by default in current Office. New in-cell checkboxes Architecturally much better — because the checkbox is part of the cell and represents TRUE/FALSE. But Microsoft’s own documentation currently lists the feature for: - Excel for Microsoft 365 - Excel for Microsoft 365 for Mac not Excel 2024 LTSC. That leaves perpetual Office users in an uncomfortable middle ground. This is where the product story becomes difficult to defend I am not claiming that Microsoft intentionally removed this behaviour in order to sell subscriptions. There is no evidence for that claim. But the resulting user experience is still hard to justify: 1. Excel can execute the legacy checkbox behaviour. 2. Excel can preserve it. 3. Excel can save it. 4. Excel accepts a manually patched workbook containing it. 5. Excel’s current object model does not provide a reliable way to recreate it. 6. The modern replacement — native in-cell checkboxes — is documented for Microsoft 365 rather than Excel 2024 LTSC. 7. The other legacy alternative, ActiveX, is now disabled by default for security reasons. For users maintaining mature Excel applications, this is a poor migration path. Why this matters beyond checkboxes This is not really a story about one checkbox property. It is about the contract users expect from long-lived productivity software. Excel workbooks are often not disposable documents. They can be: - product-management systems, - pricing tools, - engineering calculators, - operational forms, - purchasing systems, - inventory tools, - reporting applications, - or business processes maintained for ten or twenty years. When Excel continues to support the execution of an old document feature but silently prevents users from recreating an equivalent object, maintaining those systems becomes unnecessarily difficult. Backward compatibility should mean more than: “The file still opens.” It should also mean: “A user can maintain the workbook without reverse-engineering its OOXML package.” What Microsoft could do There are several reasonable fixes. Option 1 — Restore proper placement support Allow: CheckBox.Placement = xlMoveAndSize to generate the same placement state that Excel already understands for legacy controls. Option 2 — Expose the existing capability If the engine already supports it, expose “Move and size with cells” again for Form Control checkboxes. Option 3 — Provide a migration path Make the new in-cell checkbox functionality available to perpetual Excel releases as well, or provide an official conversion tool from legacy Form Controls to cell checkboxes. Option 4 — At minimum, document the limitation If this legacy state is intentionally read-only for compatibility, document it clearly. Currently, a user can spend hours debugging VBA without realizing that two visually identical Form Control checkboxes can have fundamentally different internal placement semantics. A workaround exists — but users should not need it The workaround I eventually used was to modify the .xlsm OOXML package so that newly generated controls use the same anchor metadata as the working legacy controls. That solved the problem immediately. But manually patching Office XML should not be necessary to restore behaviour that Excel itself already supports. It is a useful proof of concept. It is not an acceptable product-level solution. The reproducible evidence I have retained minimal A/B test workbooks demonstrating the problem: OLD Original Form Control checkboxes with correct legacy placement. NEW The same workbook after deleting and recreating the controls. The differences can be reproduced and inspected directly in the workbook OOXML. I would be happy to provide the files to Microsoft Excel engineering. Final thought Excel’s reputation was built partly on extraordinary backward compatibility. That is why companies still trust .xls and .xlsx files created years — sometimes decades — ago. This case shows an uncomfortable edge of that compatibility: Excel remembers how to use an old feature, but appears to have forgotten how to create it. When the workaround is to unzip an .xlsm, manually alter OOXML placement records, rebuild the package and reopen it in Excel — and Excel then works perfectly — it is difficult to argue that the capability itself is gone. The engine still knows how. The user simply no longer has a supported button or VBA path to ask for it. Microsoft, please give that capability back — or provide a proper migration path. Sources Microsoft documentation for native cell-based checkboxes: https://support.microsoft.com/en-us/excel/using-check-boxes-in-excel Microsoft-hosted discussion on Form Control checkbox limitations: https://learn.microsoft.com/en-us/answers/questions/4813119/is-there-a-way-to-assign-a-checkbox-to-a-cell Microsoft documentation on ActiveX controls being disabled by default: https://support.microsoft.com/en-us/office/vba/activex-controls-are-disabled-by-default-in-microsoft-365-and-office-2024
