The manual version of the video's one click script: same two values, typed by hand, with the megabyte maths done for you and the 95 percent warn rule explained.
The one click script in the video writes two registry values. Doing it by hand takes three minutes and has one advantage: you see exactly what changed and can undo it just as easily. The only place people go wrong is the numbers - the values are in megabytes, not gigabytes, and the warn value must stay just under the maximum.
The PST key lives under your Office version number: 16.0 for Outlook 2016, 2019, 2021 and Microsoft 365; 15.0 for 2013; 14.0 for 2010; 12.0 for 2007; 11.0 for 2003. Full path: HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\PST. If the PST key does not exist, create it - right-click the Outlook key, New - Key, name it PST. Editing the wrong version's key is the number one reason the fix 'does nothing': Outlook reads only its own.
Inside the PST key, create two DWORD (32-bit) values named exactly MaxLargeFileSize and WarnLargeFileSize. Spelling and capitals matter to the point that a typo means a value Outlook ignores completely - it will never warn you the name is wrong. Double-click each value, select Decimal (this step is forgotten constantly, because the dialog opens on Hexadecimal), and type the megabyte figure.
Multiply gigabytes by 1024. For a 75 GB limit: max 76800, warn 72960. For 100 GB: max 102400, warn 97280. For 150 GB: max 153600, warn 145920. The warn figure is always 95 percent of the max, rounded down. Never set warn equal to or above max - Outlook's behaviour past that point is unpredictable, and you lose the early warning the two-stage system exists to give you.
Close Outlook fully - confirm OUTLOOK.EXE has left Task Manager - then reopen it and send yourself a test mail. If the error is gone, the values were read. If nothing changed, check three things: you edited the version key your Outlook actually uses, the value names are spelled exactly, and the numbers were typed as Decimal. On office PCs there is a fourth possibility: a company policy under HKEY_CURRENT_USER\Software\Policies\Microsoft\Office sets the same values and silently overrides yours - that is your IT admin's setting to change, not yours to fight.
Old ANSI PST files use different value names - MaxFileSize and WarnFileSize - and it barely matters, because the ANSI format itself cannot hold more than about 2 GB. No value you type will carry an ANSI file past that wall; large numbers are simply ignored by the format. If your file is ANSI, stop raising and start converting - the ANSI emergency guide below walks through it. And whichever file type you have: Raising the limit only moves the wall. An oversized PST opens slower, searches slower and corrupts more easily, and the repair takes longer the bigger the file gets. The registry change is a bridge that buys you time - the real cure is archiving old mail out, compacting, and keeping every PST at a sensible size.
Prefer not to type registry values at all? The video's one click script writes this exact pair for you - watch how it is used.
Watch Full VideoWork through the four usual causes: the wrong Office version key, a misspelled value name, numbers typed in Hexadecimal instead of Decimal, or an IT policy under the Policies key overriding your values. Also fully restart Outlook - it reads the values only at start.
Technically the field accepts very large numbers, but practicality sets the real ceiling: every extra gigabyte is slower searching, longer repairs and bigger backups. For nearly everyone, 100 GB with a proper archive routine beats 500 GB with none.
Yes - classic Outlook applies the same PST-key values to OST files. Remember an OST is a cache of a server mailbox: if it keeps refilling to the limit, the durable fix is reducing the mailbox or the sync window, not endlessly raising the cache ceiling.