Autonumber doesn't work this way.
If you are numbering your peripherals in a separate table, the peripheral's private number is NEVER an autonumber if it is going to restart.
The way to do this is with a query. Look up DCount and then think about storing a new peripheral record based on this...
tblPrphrl
fldSrvNum - long, FK - server number
fldPrphrlNum - long - peripheral number for this server
etc.
[fldPrphrlNum] = 1 + DCount( [fldPrphrlNum], "tblPrphrl", "[fldSrvNum]=" & {the current server number in question} )
By the way, you should be aware of this, but you might not be. If it is critical to your design that server numbers be contiguously assigned, that should ALSO not be an autonumber. There, you could use DMax of the server number in your server table. Then add 1 to that. You could have also used DMax in the peripheral number.
See, here's the problem. If you assign a field as an autonumber, the moment you open that record, the number is PERMANENTLY ASSIGNED even if you abort the update or append process. (It's the only way you can share a table with an autonumber prime key.) So you would very soon notice gaps in your numbering scheme no matter what.
In general, if your field has any meaning other than a totally arbitrarily assigned number WITH NO OTHER PROPERTIES, it cannot be an autonumber. People who try to encode autonumbers are cruisin' for a bruisin' somewhere down the line.