NetBackup – не видно баз для восстановления.

Unable to browse successfully backed up SQL Server Availability Group databases

Unable to browse successfully backed up SQL Server Availability Group (AG) databases. Only system and non-AG databases are listed in the NetBackup MSSQL Client when browsing for restores

An incorrect Client Name was specified in the “Restore SQL Server objects” dialog.

SQL Server AlwaysOn Availability Group (AG) databases are automatically backed up using the Windows Server Failover Cluster (WSFC) name. When browsing for AG database backups, change the Client Name from to the correct WSFC name, which is always a fully qualified domain name. The WSFC name can be found in Failover Cluster Manager or in the job details for the backup.

Найти отключенных в AD пользователей активных в SfB

If you’ve not been disabling users in Lync while disabling them in AD, here’s a one liner to find those users:

Get-CsAdUser -ResultSize Unlimited | Where-Object {$_.UserAccountControl -match “AccountDisabled” -and $_.Enabled -eq $true} | Format-Table Name,Enabled,SipAddress -auto

You can shorten it somewhat by not checking if $_.Enabled is $true, but just that it exists. You can get a count of the users using:

Get-CsAdUser -ResultSize Unlimited | Where-Object {$_.UserAccountControl -match “AccountDisabled” -and $_.Enabled} | Measure-Object

and, if you want, can disable them in one line using

view sourceprint?

Get-CsAdUser -ResultSize Unlimited | Where-Object {$_.UserAccountControl -match “AccountDisabled” -and $_.Enabled} | Disable-CsUser

PowerShell: List All Subnets in Sites & Services

Как получить список всех подсетей в сайте AD.

Скрипт написан Джоном Догерти (John Dougherty)

PowerShell: List All Subnets in Sites & Services

## Get a list of all domain controllers in the forest
$DcList = (Get-ADForest).Domains | ForEach { Get-ADDomainController -Discover -DomainName $_ } | ForEach { Get-ADDomainController -Server $_.Name -filter * } | Select Site, Name, Domain

## Get all replication subnets from Sites & Services
$Subnets = Get-ADReplicationSubnet -filter * -Properties * | Select Name, Site, Location, Description

## Create an empty array to build the subnet list
$ResultsArray = @()

## Loop through all subnets and build the list
ForEach ($Subnet in $Subnets) {

$SiteName = “”
If ($Subnet.Site -ne $null) { $SiteName = $Subnet.Site.Split(‘,’)[0].Trim(‘CN=’) }

$DcInSite = $False
If ($DcList.Site -Contains $SiteName) { $DcInSite = $True }

$RA = New-Object PSObject
$RA | Add-Member -type NoteProperty -name “Subnet” -Value $Subnet.Name
$RA | Add-Member -type NoteProperty -name “SiteName” -Value $SiteName
$RA | Add-Member -type NoteProperty -name “DcInSite” -Value $DcInSite
$RA | Add-Member -type NoteProperty -name “SiteLoc” -Value $Subnet.Location
$RA | Add-Member -type NoteProperty -name “SiteDesc” -Value $Subnet.Description

$ResultsArray += $RA


## Export the array as a CSV file
$ResultsArray | Sort Subnet | Export-Csv -Encoding UTF8 .\AD-Subnets.csv -nti


Find all domain controllers in domain

Получить список всех контроллеров домена.

Using powershell one can find all domain controllers in domain using:

1. a LDAP filter:

Get-ADComputer -LDAPFilter “(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))”

2. “Domain controllers” group and retreive his memebers:

Get-ADGroupMember ‘Domain Controllers’

3. Get-ADDomainController cmdlet:

Get-ADDomainController -Filter * | Select-Object name

SfB – “A call to a PSTN number failed due to non availability of gateways.”

В логах очень часто возникают ошибки “A call to a PSTN number failed due to non availability of gateways.
Описание и решение ниже по ссылке.

Спасибо автору – Y0AV. WITH A ZERO.!
“The odd call drops” of the Mediation Server

I had a very annoying issue lately when an installation of a new gateway resolved in some calls (specifically to US numbers) dropped by the Skype for Business mediation server saying “A call to a PSTN number failed due to non availability of gateways.

The cause, according to the mediation server, was that “All gateways available for this call are marked as down“, and the resolution, surprisingly, was to “Verify that these gateways are up and can respond to calls.”

It seemed funny, because all other calls were successful, I have not exhausted the available PRI channels I had, the gateway didn’t seem to lose connectivity for a split second and SIP options are accepted and replied to on both ends.

Looking further at the Lync Monitoring Reports, I noticed the following:

Reported by Client
12000; reason=”Routes available for this request but no available gateway at this point”

Reported by Server
12000; reason=”Routes available for this request but no available gateway at this point”

I went to the gateway (AudioCodes M1000B) for answers and the logs were showing something very weird;

Every call starts with the same flow:

Flow1The mediation server sends a SIP Invite that will normally be answered immediately by the gateway with a “100 Trying”. This, for me, will close the deal on the “Gateway no responding” – this is a great response if you ask me.
The next phase would be the gateway immediately sending a “PSTN Place call” to the PSTN, hopefully receiving a “Proceeding” instantly from the PSTN, meaning so far we’re fully communicating. So for the time being I’m not really buying what the Lync mediation server is selling.

Looking further at the logs, I see the following strange behaviour:
As I’m still waiting for the PSTN to connect the call (this would normally be a “PSTN Call Alerting” message), I see that the mediation server decided to abandon ship!
This is what I see in the logs:


Within 10 seconds after initiating the call, the mediation server will send a “Cancel” request to the gateway and will terminate the call:

19:25:49.640 [S=660986] [SID:1327438938] INVITE sip:+353857560598@;user=phone SIP/2.0 
19:25:49.729 [S=661027] [SID:1327438938] SIP/2.0 100 Trying 
19:25:49.730 [S=661035] [SID:1327438938] (   lgr_psbrdif)(    656225)   pstn send --> PlaceCall
19:25:50.087 [S=661039] [SID:1327438479] (   lgr_psbrdex)(    656229)   pstn recv <-- CALL_PROCEEDING
19:25:59.020 [S=661055] [SID:1327438938] CANCEL sip:+353857560598@;user=phone SIP/2.0 
19:25:59.052 [S=661061] [SID:1327438938] SIP/2.0 200 OK 
19:25:59.058 [S=661065] [SID:1327438938] SIP/2.0 487 Request Terminated 
19:25:59.079 [S=661074] [SID:1327438938] (   lgr_psbrdif)(    656265)   pstn send --> PSTNDisconnectCall

Clearly, the gateway is available and responding, but the mediation server is somewhat impatient.

Doing a bit of digging around, it appears there’s a setting for this.

The Lync mediation server is expecting a “SIP 180 Ringing” within 10 seconds of initiating the call. Failing to provide that (183 “Session in Progress” can be pushed here but that won’t benefit you if you’re still waiting for that ring…) will cause the mediation server to decide that the call didn’t respond and to mark the gateway as unavailable. A little too harsh? In my opinion yes. This will generate errors (2 per failed call) on your Lync servers and is actually a Lync self-inflicted error.

To work around this issue you can go to:
<Lync or Skype for Business installation folder\Server\Core
and look for a file called “OutboundRouting.exe.config“.
When you open that file, the first configuration line is:
<add key=”FailOverTimeout” value=”10000″/>
This actually determines how long should a call wait for the gateway until it declares it “Offline”. the value is in milliseconds, meaning the default setting is 10 seconds.

This will impact your environment if you have two or more gateways, and it means that it’ll take the mediation servers more than 10 seconds to declare that gateway as offline if it actually fails.

For me to workaround that issue I extended the wait time to 20 seconds, restarted the front-end and mediation services, and all of a sudden no call was dropped.

It appears it took the carrier approx. 12 seconds to generate the “PSTN Call Alerting” command to the gateway. For some reason, only calls to the US (and only with this specific carrier) were affected by this issue.

Now, I can see all my calls working perfectly and the errors have disappeared from the serves too.

Защита от спама в Exchange 2013: RBL

Защита от спама в Exchange 2013: RBL

Чтобы установить агент Connection Filtering, нужно воспользоваться командлетом Install-TransportAgent:

Install-TransportAgent -Name “Connection Filtering Agent” -TransportService FrontEnd -TransportAgentFactory “Microsoft.Exchange.Transport.Agent.ConnectionFiltering.ConnectionFilteringAgentFactory” -AssemblyPath “C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\Hygiene\Microsoft.Exchange.Transport.Agent.Hygiene.dll”

После установки агента, его нужно включить и перезапустить службу Front End Transport:

Enable-TransportAgent -TransportService FrontEnd -Identity “Connection Filtering Agent”
Restart-Service MSExchangeFrontEndTransport

Проверить, что агент фильтрации подключений установлен и работает можно так:

Get-TransportAgent -TransportService FrontEnd

Далее нужно задать используемых RBL провайдеров.

Примечание. Самыми популярными RBL провайдерами на данный момент являются Spamhaus и SpamCop.
Add-IPBlockListProvider -Name -LookupDomain -AnyMatch $true -Enabled $True

Чтобы изменить текст отбойника, возвращаемого отправителю, воспользуемся такой командой:
Set-IPBlockListProvider -RejectionResponse “Your IP address is listed by Spamhaus Zen. You can delete it on page”

Можно добавить сразу несколько RBL провайдеров, предварительно ознакомившись с их особенностями и политикой коммерческого использования.
Список используемых RBL можно вывести так:


Get-IPBlockListProvider – список используемых RBL сервисов

Проверить наличие конкретного IP адреса на предмет присутствия в RBL списке можно так:

Test-IPBlockListProvider -Identity -IPAddress x.x.x.x

Логи агента Connection Filter по умолчанию сохраняются в каталог
C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\AgentLog

После накопления первичной информации (зависит от объема почтового трафика, в среднем два – три дня), статистику результатов работы RBL фильтрации можно посмотреть с помощью командлета Get-AntispamTopRBLProviders.ps1

.\get-AntispamTopRBLProviders.ps1 -location “C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\AgentLog”


Туда же

Установка и настройка защиты от нежелательной почты Exchange 2013 / 2016 (антиспам)

Спасибо автору за краткий и понятный пост.

Best practices for DNS settings on DC and domain members.

Best practices for DNS settings on DC and domain members.

Украдено тут

The following information explains the Best practices for DNS client settings on Domain Controller and Domain Member.

Domain controller with DNS installed:
On a domain controller that also acts as a DNS server, recommended that you configure the domain controller’s DNS client settings according to these specifications:

IP configuration on domain controller:

  • In single DC/DNS in a domain environment,  DC / DNS server points to its private IP address (not to loopback 127.x.x.) as preferred DNS server in TCP/IP property.
  • If multiple DCs that’s the DNS servers are in a domain environment, recommendation to have all DCs point to ANOTHER/REMOTE DC’s IP address as preferred DNS and then point to it’s private IP address as an alternate DNS.
  • Each DC has just one IP address and one network adapter is enabled (disable unused NICs).
  • IPv6 should not be disabled on DC’s NIC card. Set it to “obtain IPV6 address automatically” and “obtain DNS server address automatically”
  • If multiple NICs (enabled and disabled) are present on server, make sure the active NIC should be on top in NIC binding.
  • Contact your ISP and get valid DNS IPs from them and add it in to the forwarders, Do not set public DNS server in TCP/IP settings of DC.

How to set/view the NIC bind order in Windows

IP configuration on domain member:

  • Each workstation/member server should point to local DNS server as preferred DNS and remote DNS servers as an alternate DNS server in TCP/IP property.
  • Do not set public DNS server in TCP/IP setting of domain member.

Once you are done with above, run “ipconfig /flushdns & ipconfig /registerdns“, restart DNSserver and NETLOGON service on each DC.

Quick note: MULTIHOMED domain controller is not recommended, it always results in multiple problems.

  • Being a VPN Server and even simply running RRAS makes it multi-homed.
  • Domain Controllers with the PDC Role are automatically Domain Master Browser. Master Browsers should not be multi-homed

Active Directory Communication Fails on Multihomed Domain Controllers;en-us;272294

Symptoms of Multihomed Browsers;EN-US;191611


Как найти активные учетки в домене.

Ниже самый простой и доступный способ.

Активные и отключенные пользователи домена Active Directory

Открываем «Active Directory – пользователи и компьютеры», выбираем «Сохраненные запросы». Создаем запрос, задаем Имя и Описание, нажимаем «Запрос», выбираем «Пользовательский поиск», переходим в «Дополнительно» и вставляем текст запроса.

Включенные (незаблокированные) учетные записи в домене

Отключенные (заблокированные) учетные записи в домене


Используем dsquery

Так же возможно использовать системную утилиту dsquery, но активных пользователей она не показывает, только отключенных

dsquery user -inactive 12 -limit 10000


Украдено тут