These are easy fixes with several alternatives depending on what makes the most sense.
First option, you can reduce the units per resource on the resource page. So, if you have a person who also performs non project related stuff on an uncertain basis, estimate what remains. No one is ever really 100% available. So, using 60%, 70%, or 80% is appropriate. If you did it this way, then you need to set all of your tasks as fixed unit. Plug in your target hours and project will calculate the appropriate duration.
Second option, if some of those meetings, both scheduled or ad hoc, are project related even in the most remote way, then either up your work estimates to include that work or up your duration. For example, if you have your task as 'fixed work', you plug in 8 hours, extend your duration to 1.5 or 2.0 days, and project will calculate the resource utilization to something less than 100%. Or, make your task fixed duration, manually enter 1.5 or 2.0 days, keep your resource at 70% units, and project will calculate the hours.
I find using fixed duration the easiest and keeping the resources either at 50% for part-time or 100% for full-time. I manipulate the duration such that I am providing enough time for wrench turning (full productivity) as well as all the other stuff that pops up. The down side in doing it this way is you have to watch the utilization for each person to ensure you are not over burdening his/her day. It requires some leveling. But MSProject is quirky and this seems to be the best way to overcome its constraints.
EDIT: When you estimate time for a task and enter it into a scheduling tool, you are taking a non deterministic estimate and choosing a single value, a deterministic value. For example, you may estimate 3 to 8 days for a task with a most likely finish of 5. You cannot schedule a range so you choose a target that represents the level of your risk appetite. Five or six days is reasonable and that is what you schedule. However, that inherently means you have some risk of exceeding your target up to 8 days in this example, due to all kinds of interruptions like ad hoc meetings, your people getting pulled on their other projects if they're shared, unexpected issues, etc. This does not make the schedule wrong, it causes variances against which you have to manage.
The schedule does not run you; you run the schedule. If your scheduling is saying a task starts now but your resource is not there, that is called a late start. Plug it in your tool as actual start date and keep going. Your schedule will NOT come true with a zero variance.