Все таки все вышло гораздо интереснее, чем казалось.
Можно. Можно посредством Powershell мигрировать квоты между серверами. Главное - чтобы совпадали имена дисков и путей. А теперь более развернуто.

Сначала камнем преткновения стал параметр -SoftLimit. Синтаксис его таков:
для задания мягкой квоты: New-FSRMQuota -path "blah" -size "blah" -softlimit
для задания жесткой квоты: New-FSRMQuota -path "blah" -size "blah"
то есть если нужен хардкор - параметр не указывается вовсе. Черт, а ведь я хотел бы более привычное -softLimit $True/$False. И как же это побороть? Читаем описание самого параметра и видим:

Accept Pipeline Input? True (ByPropertyName)

А это означает, что весь командлет New-FSRMQuota можно натравить на трубу, через которую будет передан объект, описывающей имеющуюся на сервере источнике квоту. будет примерно так:

Get-FSRMQuota | New-FSRMQuota

Произойдет следующее. Команда Get-... занесет в память объект с кучей свойств, в том числе будет и свойство -SoftLimit. Все это добро будет передано по трубе команде New-..., которая, зная, какие свойства в новом объекте надо заполнить, будет их по имени искать в переданном объекте. Найдет - подставит, не найдет - пропустит. Отлично, с этими разобрались.

Следующее: если в командлете New-FSRMQuota нет параметра вида -ComputerName, который бы сказал, где именно запускать процесс, то каким образом можно:
1. ухитриться запустить на удаленной машине
2. передать параметры квоты на эту самую удаленную машину.
Ответом на первый вопрос стал параметр -CIMSession. Идентификатор сессии, который можно предварительно задать при помощи командлета New-CIMSession. Этот параметр выступит полным аналогом так нужного мне -ComputerName. А со вторым оказалось все до боли просто - та же самая труба. То есть получаем вот такую конструкцию:

$session = New-CimSession -ComputerName FS2
Get-FSRMQuota | new-fsrmquota -CimSession $session

В итоге команда Get-... выполнится в локальной сессии, а New-... - в удаленной, при этом в качестве входных параметров будет использован объект, полученный в локальной сессии. Удобно!

Но не тут-то было. Идилия была просто разбита в кровь одной особенностью квот. Шаблоны. МС настоятельно рекомендует, чтобы все квоты были привязаны к какому-либо шаблону. Но ведь это не всегда так. В данном случае примем условимся, что шаблоны на обоих серверах совпадают. Вариант с разными шаблонами я не рассматриваю, там еще нужно огранизовать сначала миграцию самих шаблонов, а сейчас такой задачи не стояло.

А сама особенность заключается в следующем. Если в переносимой квоте не задан шаблон, то при выполнении конструкции Get-FSRMQuota | new-fsrmquota -CimSession $session команда New-... попытается создать новую квоту с параметром -Template, равным пустой строке. Логично, шаблон ведь не задан. И именно на этом моменте она выкинет ошибку. Если команда New-... вызывается с указанием параметра -Template, а в нашем случае он будет указан по-дефолту, то этот параметр просто обязан не быть равным пустой строке. Получается, еще до выполнения New-... нам придется анализировать, а была ли квота подвязана к шаблону, и если не была - то на вход команды New-... нужно передавать уже другой объект, в котором были бы все свойства исходного, кроме -Template. Ну что же, это выполнимо (в переменной $quota как раз хранится объект, описывающий квоту):


Ну а если суммировать все, что тут было написано - получается примерно такой скрипт: