MVV

Используйте метод Task.WaitAll
Ссылки на все эти задачи, при этом надо, кончено не бросать без присмотра при перезаписи переменной outer, а сохранить (например, в массив Task[])

Возможно проблема в чистке журнала транзакций (база переводится в simple, shkrink ну и обратно в full), но на другом сервере проблем не наблюдаю с этим.

Да, это как раз может вызывать вашу ошибку: если после полного резервного копирования происходит изменение модели восстановления базы (full->simple->full), и в момент, когда БД находится в simple, происходит усечение журнала транзакций, то цепочка записей транзакций после полного копирования оказывается нарушенной. А если усечения не происходит, как на другом сервере, - то вам везет. Поэтому так, как вы делаете, делать не надо.
Вы сжимаете именно журнал транзакций, а не саму БД, я правильно понял? В таком случае посмотрите, а надо ли это вам. Потому что резервное компирование журнала транзакций очищает занятое место в его файле. И это место в дальнейшем (через некоторый промедуток времени - после переключения на другой логический журнал) может использоваться повторно. В результате в стационарном случае - при примерно одинакой частоте трназакций - файл журнала расти перестает.
Если же вам действительно потребуется сжать журнал - например, после массовй операции типа загрузки большого объема данных - то это можно сделать, не меняя модель восстановления БД. Делается это последовательностью операций "резервное копирование журнала"->"повторное резервное копирование журнала"(лучше после паузы, чтобы преключение на следующий пустой логический журнал, который будет в начале файла, точно произошло)->"усечение журнала с конца"(truncate). Иногда, правда, эту последовательность может потребоваться повторить (если переключения на пустой логиченский журнал в начале файла не произошло).
А усечение журнала трназакций с конца - это очень быстрая операция (потому что никакие записи журнала никуда не перемещаются), так что ее можно делать обычно даже в период номинальной нагрузки, днем.

В Exchange Management Shell (который Powershell) командой:

Set-SendConnector -Identity <SendConnectorIdParameter> -FQDN <fqdn>

SendConnectorIdParameter - имя соединителя, через который идет отправка почты в Интернет
fqdn - имя, которое разрешается во внешний белый IP сервера, желательно чтобы IP-адрес разрешался в это имя (этот вопрос решается с провадером: нужно изменить или добавить в зоне обратного разрешения запись PTR).

Дошёл до более менее адекватной ошибки, это указав ObjectName \\Domain\User 555555, получаю

Попробуйте Domain\User, имя пользователя часто указывается так. Domain тут - имя домена AD, в котором существует пользователь - при условии что компьютер включен в этот домен или в домен, который доверяет этому. Если компьютер не в домене или пользователь - локальный, то вместо имени домена указывается имя компьютера.

SomethingFuncCatch().Wait();
В Wait дополнительно можно передать таймаут и/или CancellationToken (см. описание метода Task.Wait ).

Только вот, боюсь, что вы не дождетесь когда закончится цикл

while (i > 0)
{
    Console.WriteLine("NewProcess started");
    i = i--;
}

Ибо вы в нем пытаетесь присвоить i то значение, которое было до уменьшения на 1.

Вынесено из комментариев.
Василий Банников , ну, что вам на это сказать?

Сильно легче код писать таким образом.

Писать - да, читать - it depends, как говорят англичане.

Если тебе сложно понять смысл кода без типов - значит кто-то плохие имена дал переменным.

А разве в legacy 4-5-летней выдержки, над которым поработало много программистов, хороших и разных, по-другому бывает? А ещё имена могут дать хорошие, понятные - но основанные на системе понятий, которая нетривиальна и не попала при этом в документацию. Чтобы понять, о чем я - попробуйте почитать исходники подсистемы маршрутизации в ASP.NET Core. лучше всего - после работы с чем-нибудь типа MVC или Razor Pages: сомневаюсь, что вы сразу въедете, что Model там и Model тут - это разные Model.

А ещё бывает, что методы называются почти одинаково, но типы значений у них разные. Пример: builder.Services.AddOptions() и builder.Services.AddOptions<TOptions>() из кода конфигурирования контейнера сервисов, методы расширения IServiceCollection для Option Patterns - типы возвращаемых значений у них разные. А их ещё любят цеплять друг к другу к таким же методам через точку - вот и смотри потом, чой-то в ConfigureOptions какие-то лишние параметры вылезли.

с анонимными типами без var работать было бы очень сложно.

Правильный вопрос - зачем вообще заставлять работать с анонимными типами? Подозреваю, что их из-за маршрутизации в MVC завезли - как типы параметров, вместо того, чтобы передавать в методы генерации ссылок вместо IDictionary<String,Object>, как это оно там реально требуется. Но, в Microsoft решили, видимо, тогда не делать инициализаторы для словарей (при том, что потом всё равно сделали, не отвертелись), а притащить вместо них анонимные типы (интересно откуда - неужели прямо из JS?). Но это не точно. (Ага, в комментарии мне напомнили про LINQ)

Тренд говорит об обратном - автоматический вывод типов сейчас есть практически во всех статически-типизированных языках в том или ином виде.

Это потому что сейчас главное - быстрее писать MVP, для веба - особенно. Ну, а потом можно сказать волшебное слово: "Legacy".

Ну и помни ещё, что ты же не в блокноте код пишешь

Но читаешь-то ты его не только в IDE. В частности, MS в своей документации на сайте в примерах очень любит писать var - вот и выбирай потом, что делать: лезть прямо сразу в документацию по API (а ссылки отнюдь не прилагаются) или рисковать упустить что-то важное? А если ещё учесть, что сейчас принято документацию ограничивать примерами (MS любит, да) - оно вообще весело.

Но, с другой стороны, автор вопроса, похоже, с трех- и более этажными дженериками ещё не сталкивался (ну, или забыл, как они выглядят) - там без var тоже грустно.
Как-то так

Отмены задач используются, как ни странно, для отмены задач. А чтобы отменить задачу, это должно быть кому-нидуь нужно. Например, этим "кем-нибудь" часто бывает пользователь, которому результат задачи перестал быть нужным.

В качестве примера: пользователь послал на сервер через веб-страницу запрос и ждет результата. Представим, что запрос - сложный, результат так сразу не получить, запрос выполняется, а пользователь ждет, потому что всё это понимает. Потом пользователю внезапно надоедает ждать и он посылает команду Отменить. Или - закрывает страницу. Так вот, по-хорошему, в этом случае надо отменить задачу, которая выполняет запрос, чтобы она не тратила впустую ресурсы сервера.

А ещё отмена полезна для прерывания процессов потенциально бесконечных, типа смотреть, как горит огонь, как течет вода, как люди работают... :-)

Таймауты тут не помогут в обоих случаях. В первом случае пользователь сам часто не знает, сколько он согласен ждать, а во втором - вообще нет никакого таймаута, ибо процесс бесконечен.