Sorry, I missed the "how to avoid it part" in my first post confirming the behavior. I actually had a hard time duplicating the behavior until I used a long running select against the table. I originally had 5 PoSH sessions running a Select MAX(I), COUNT(*) from table in a loop to try to generate some activity on the table, but that query was quick enough that even with the 5 sessions looping the RESEED could sneak in, get the SCH-M lock and make the change in between queries. When I put a single long-running query (Select * From table) that held a S lock long enough to keep the RESEED from getting the SCH-M lock. How to avoid it is hard, but the first step would be to try to find a time with the least activity to run it in, even if you had to run it before you filled in one of the gaps you have. The other thing is to try to identify long-running selects and try to tune them down so you can get in and get the SCH-M lock to run the RESEED operation.