As with practically any change to workflow, your first step is to get buy-in from the Team. If I were you, I'd bring the problems you're trying to solve up during a Retrospective meeting, and ask for suggestions. It's possible one of the Development Team members will bring it up themselves - this will make it go down much easier than a mandate. It's also possible they might suggest an alternative suggestion which could work just as well (such as, say, code review) - depends on your actual requirements. If neither happens, then you could bring it up yourself for discussion. The only two ways I know of to avoid a practice being a 'flash in the pan' are either to get team buy-in or have an executive mandate - the latter of which could end up reducing performance, rather than improving it.
As for best practices, I know of three. First, it's best if junior programmers are paired with senior programmers, with the junior usually being the driver and the senior usually being the navigator (note that this works only if the senior is actually more skilled/knowledgeable, not just has higher seniority on a corporate ladder). Second, both need their own computers at a single desk - while the driver is programming, the navigator should be free to look things up on their own machine. Third, you should switch the pairs up every now and then - knowledge dissemination works best if your pairs aren't static.
Regarding the remote worker, that presents a lot of problems - especially if they're in a different time zone. If you're going to have to alter people's working hours in order to even get people to be able to pair program, then my suggestion would be to just forget it and keep to code reviews instead. If you don't have to worry about that, then at the very least you'll need some sort of screen-sharing software (so the navigator can see the driver's code; ideally the driver should be able to see what the navigator looks up, as well, so you'll need to share both ways) along with voice chat at the very minimum, preferably with video as well. You might even need three monitors per person - one for the shared screen, one for video chat, and one for IDE (driver) / browser (navigator). As a disclaimer, I've never tried remote pair programming before, but I imagine the setup listed above would be the minimum necessary to get anything close to the same experience as in-person.