Mechanism to get 10 pseudo-random positive numbers up to maximum from a seed (32-byte hash)? I have learned new crypto words, so I rewrote the question:

I have quite random 32-byte hash which I want to use as a seed for generation of 10 pseudo-random positive numbers up to some maximum number, the generation must be reproducible. I would prefer, if those 10 numbers would differ from each other.

There is an example: 

hash=Pkq5skE7tp=j#{y"+R$6~mg!z"4g/Utwand I need to reproducibly generate count=10 pseudo-random positive numbers up to say max=500. 

So approaches that came to my mind: 
1) I can take first 8 bytes Pkq5skE7 and cast them to 64-bit integer, then use modulo 500 on the result and have first number, then take other 8 bytes starting 1 byte right kq5skE7t, cast it, modulo it and get second number and I can get all 10 number like that. 
Would those numbers seem pretty random or would they have some pattern? 
There is not preferable effect of having 2 numbers the same. 
2) I can take first 8 bytes Pkq5skE7 and cast them to 64-bit integer, then use modulo 500 on the result and have first number, then calculate other numbers with adding 500/10=50 to the result. So if the result of the cast would be 475, then other numbers would be 25, 75, .., 425. 
I know that there is randomness only for the first number, but that would be good enough if method 1) would have some inconvinient pattern problem (like numbers distributed close to each other or something). 
Compared to 1), numbers would be unique and that is an advantage. 
3) If methods 1) and 2) won't be very good, I can again cast some bytes to 64-bit integer, do modulo, get number and take 9 numbers from following positions. 
But that loses the random-like factor and I would prefer if the 10 numbers' would seem random and not much related to each other, the same problem can be said for 2), but it's preferable to have the numbers distributed over the whole spectrum. 
4) Some other approach?

Basically I prefer 1), but maybe there is something better that can't yield the same number twice, maybe numbers from 1) can have a lot in common, because it's just shifting 1 byte right, I don't know. 

I can tell it's used for something like drawing in a lottery. It is preferable that the numbers don't have relationship between each other, but I am not sure, if it's possible and maybe it's ok for those numbers to just look like pseudo-random and only the first being pseudo-random and other having not-obvious relationship to it.

Suggestions?
The best way to do this would probably be through an iterative hash, where you use that seed as an input, and from each iteration you extract a certain amount of bits for conversion to a number. A 32-bit extraction allows numbers up to around 4 billion.

I would do it as follows:

A = Hash(Seed)
Extract1 = lower 32-bits of A
Number1 = Extract1 mod (MaxVal)
B = Hash(A)
Extract2 = lower 32-bits of B
Number2 = Extract2 mod (MaxVal)
... and so on

This will prevent the numbers from having any special relationship with eachother, other than the fact they use the same seed, your suggested example means that the next number directly depends on half the previous number plus an additional 8-bits of unknown information. For a lottery that would be bad. This method means the output depends pseudorandomly on an additional 224-bits of information (assuming the hash is 256-bits).

The iterative sequence is deterministic and will always produce the same values from a given seed, and can generate both enormous numbers as well as enormous quantities of numbers, if needed.

If you want to be able to publish proof of the seed PRIOR to the lottery draw, you can post a digital signature of the seed, that way players would be assured you are not going to manipulate the seed after players are selected in order to generate winning values for a specific player. Just makes sure the signature uses a different hash function.