In our environment, users were granted read/write/ddladmin permissions on tempdb database (dev/qa/prod).
These permissions will be lost when SQL Services restart, as tempdb rebuilds every time. One solution that is currently in place is – reapply the permissions scripts from a SQL Agent job, when ever SQLAgent starts. This is not accurate, as the users/permissions will be modified over time. Another thought, is take a daily backup (with a 15day retention policy) of tempdb permissions and use the same job to pick the latest file to reapply the permissions when SQL restarts. Is this an accurate solution for the problem.
An alternative to modifying model might be to create a stored procedure in the master database that contains whatever you need to do. Then you mark this as startup proc (sp_procoption).
You might have to put in a WAITFOR in there in case SQL Server executes this before model has been recovered and tempdb has been created. For you to play with.
I’ve only used startup proc occasionally, so make sure you do thorough testing.
And, I fully agree with J.D.: modify them jobs instead, if at all possible.
If you read the top accepted answer on the StackOverflow you linked, it takes a step back and asks the question “why are you creating permissions for users on TempDB”? They’re unnecessary for users to create, access, and manage temporary objects in it. The permissions you mentioned are already implicitly granted to all users with Connect access to the server, for temporary objects. So you shouldn’t have to worry about TempDB being recreated.
(The only time these permissions matter is if you wanted your users to create non-temporary objects in the TempDB database which wouldn’t make sense and be a bigger issue to manage than the permissions themselves.)