Linux – Resolvendo erro: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

Passei por isso e resolvi compartilhar com vocês.

Caso apareça uma mensagem parecida com esta para você:/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
fsck died with exit status 4.

Isso ocorre devido um erro na consistência de arquivos causados por uma ma atualização do sistemas ou desligamento repentino incorreto do sistema, para resolver execute esse comando como root:

# fsck.ext4 /dev/sda1
ou
# fsck.ext3 /dev/sda1
ou
# fsck.reiserfs /dev/sda1

e reinicie a máquina.

Sendo sda1 é a partição problemática citada por sua mensagem.

Migração do Servidor de Arquivos com as Ferramentas de Migração do Windows Server - Além do Robocopy

Para quem trabalha com infra-estrutura sabe o quanto é trabalhoso e “perigoso” migrar o servidor de arquivos, pois a migração deve envolver a transferência dos dados, bem como o controle de acesso (permissões), ou seja, quem tinha acesso antes da migração deve continuar a ter acesso, e quem não tinha acesso deve continuar a não ter.

Para ajudar nesse processo a Microsoft incluiu no Windows Server 2012 um módulo do Windows PowerShell que contém 5 cmdlets, esses cmdlets são chamados de Ferramentas de Migração do Windows Server. Existem dois cmdlets (Send-SmigServerData e Receive-SmigServerData) que trabalhando em conjunto permitem migrar “ao vivo” os compartilhamentos de arquivos e suas permissões para outro servidor.

No exemplo desse artigo o servidor origem é o Windows Server 2003 SP2 e o servidor de destino é o Windows Server 2012. Vou assumir que as Ferramentas de Migração já estejam instaladas em ambos os servidores.

Obs.: A instalação das ferramentas de migração são abordadas no meu artigo: Instalação das Ferramentas de Migração do Windows Server.

Vamos migrar o compartihamento Home Users, esse compartilhamento contém uma sub-pasta privativa para cada usuário. Veja a estrutura na imagem abaixo.

Observe a guia Segurança da pasta User1. Veja que somente os Administradores do domínio, o sistema, e o próprio usuário possuem acesso a pasta.

Supondo que as Ferramentas de Migração do Window Server já estejam instaladas no servidor de origem e no servidor de destino, siga os procedimentos a seguir:

1. No servidor de origem clique em: Iniciar >Ferramentas de Administrativas >Ferramentas de Migração do Windows Server >Windows Server Migration Tools.

2. A  transferência dos dados é criptografada por uma senha, por isso vamos criar um objeto de senha do Windows PowerShell:

$pwd = (Read-Host “Digite a Senha” –AsSecureString)

3. Agora vamos enviar os dados, as configurações de compartilhamento, e as permissões NTFS para o computador SRV-2012.

Send-SmigServerData -include All -Computername SRV-2012 -SourcePath "C:\Home Users" -DestinationPath "H:\Home Users" -Recurse -Password $pwd -V

4. No servidor de destino Abra as Ferramentas de Migração do Windows Server

5. Crie um objeto de senha do Windows PowerShell com a mesma senha utilizada na etapa de envio. (Informe a mesma senha utilizada no envio dos dados.)

$pwd = (Read-Host “Digite a Senha” –AsSecureString)

Receive-SmigServerData –Password $pwd

Após o termino do processo de migração, verifique no servidor de destino as pastas, os dados, e as configurações de compartilhamento e NTFS.

6. Após a confirmação de que a migração ocorreu com sucesso, desconecte o servidor antigo da rede e refaça os mapeamentos de rede para apontarem para o novo servidor.

Obs.: Não copie e cole os comandos. Ao invés disso digite-os (a formatação pode invalidar o comando)

Que tal vocês testarem os seus conhecimentos hacker?

O pessoal que mantêm o www.100security.com.br/ acaba de lançar um wargame, uma ambiente controlado, vulnerável liberado para galera testar os seus conhecimentos hacker.

Mais detalhes poderão ser obtidos na seguinte URL www.100security.com.br/wargame

Pensar fora da caixa é fundamental, as vezes o que você acha improvável pode revelar segredos valiosos.

Windows – Onde o Usuário Logou ou está Logado?

Saber em qual Computador ou Servidor um determinado Usuário Logou ou está Logado pode ser necessário em um processo de Auditoria, e como já é de conhecimento de todos temos inúmeras formas de fazer isso, há muitas ferramentas que podem auxiliar neste levantamento.

Meu objetivo com este artigo é mostrar algumas das formas mais básicas e funcionais de se fazer isso em um ambiente de rede.

// Espero que possa ajudar alguém, deixe seus comentários sobre as formas ou soluções que você utiliza para ajudar outras pessoas.

Cenário:

Para facilitar o entendimento montei o cenário abaixo onde o objetivo é localizar onde os usuário 100SECURITY\marcos logou ou esta logado.

OPÇÃO 01 – PsLoggedon

Utilizando a ferramenta PsLoggedon.exe da SysInternals você pode saber quais usuários estão logados em um determinado host.

Download: technet.microsoft.com/en-us/sysinternals/psloggedon.aspx

01 Passo

Após descompactar o arquivo PSTools.zip entre no diretório PsTools e execute o comando:

C:\>cd PsTools

C:\PsTools>PsLoggedon.exe -x \\SRV-2008

Resultado:

Os usuários abaixo estão logados no Servidor SRV-2008:

SRV-2008\Administrator
100SECURITY\marcos

OPÇÃO 02 – qwinsta e rwinsta

Você pode utilizar o comando responsável por exibir as informações sobre as sessões dos Serviços de Área de Trabalho Remota: qwinsta

01 Passo

Execute o comando qwinsta seguido do parâmetro /SERVER:<HOST>

C:\>qwinsta /SERVER:SRV-2008

Resultado:

São exibidas as sessões remotas que estão ativas no servidor SRV-2008

02 Passo

Caso você queira finalizar uma das sessões ativas basta utilizar o ID da sessão.

Execute o comando rwinsta

C:\>rwinsta 1 /SERVER:SRV-2008

ID 1 – Corresponde ao usuário Administrator

Em seguida execute o comando qwinsta novamente para certificar que a sessão foi finalizada.

Confirmando no Servidor: SRV-2008

OPÇÃO 03 – Active Directory | EventViewer | PowerShell

Quando um usuário loga no domínio o acesso é registrado no evento 4624 do Log Security e através deste evento é possível identificar em qual o ip do computador que o usuário esta ou estava utilizando no momento deste logon.

01 Passo

Dentro do servidor de Active Directory no exemplo DC-2012 acesse o Event Viewer > Windows Logs > Security e clique na coluna EventIDpara filtrar todos os eventos, em seguida localize o evento 4624

02 Passo

Escolha uma data e de um duplo-clique no evento 4624 para visualizar todo seu conteúdo.

Observe as linhas:

Account Name: marcos – Exibe o usuário que se logon no domínio.

Source Network Address: 192.168.1.201 – Informa em qual host o usuário marcos se logon, este IP refere-se ao servidor SRV-2008.

03 Passo

Utilizando o Power Shell você pode extrair todos os logons realizados pelo usuário marcos, basta executar o script abaixo:

// Crie a pasta auditoria para centralizar os relatórios.

PS C:\>cd .\auditoria
PS C:\auditoria>Get-EventLog -LogName Security -InstanceID 4624 | Where {$_.Message -match “Account Name:\s+marcos“}

Resultado:

Mostra que o usuário marcos se logou no domínio através do host 192.168.1.201

OPÇÃO 04 – Relatório de Conexões RDP em um Servidor

Este script em Power Shell vai ajudá-lo a identificar todos os LOGON/LOGOFF que foram realizados em um ou mais servidores incluindo o computador que foi utilizado para o acesso.

01 Passo

Realize o download do script: clique aqui em seguida execute-o.

PS C:\>.cd .\auditoria
PS C:\auditoria>.\relatorio_rdp.ps1

Resultado:

A data esta no formato americano mas você pode customizar o script como quiser.

Veja mais em: http://www.100security.com.br

MELHORES PRÁTICAS PARA PROTEGER O ACTIVE DIRECTORY

Conforme o tempo vai passando os domínios vão se modernizando, com novas estações, usuários e aplicativos inseridos. Mas com a atualização dos domínios, outras partes da infraestrutura vão sendo esquecidas e acabam dando brechas para ataques. Os invasores aproveitam destas lacunas para se inserirem no domínio e conseguirem senhas e privilégios de usuários importantes no seu Active Directory através de keylogger instalados na estação.

E é por causa da demanda cada vez maior, que temos que ter noção de como os invasores atacam o AD e saber quais são as melhores práticas recomendadas pela Microsoft.

Algumas das partes da infraestrutura que acabam sendo “esquecidas” com o passar do tempo e acabam dando brechas para ataques, são:

• S.O e aplicativos obsoletos: sistemas em que os fornecedores não dão mais suporte aos mesmos, acabando não surgindo novos upgrades para corrigir falhas;

• Antivírus: não fazer a atualização dos antivírus nas estações e nos servidores, dando mais vulnerabilidade ao seu ambiente;

• Dispositivos de funcionários pessoais ligados em rede: o uso compromete o seu domínio, uma vez que não sabemos quais programas estão instalados nestes dispositivos;

• Utilização de ambientes mistos: é o uso de sistemas Microsoft e não Microsoft em seu ambiente, uma vez que acabam dando mais atenção à um e esquecendo do outro.

Algumas das práticas recomendadas para proteger seu AD são:

• Monitorar Logs referentes ao Active Directory;

• Fazer a desativação do usuário administrador local nas estações. (Caso precise utilizar o administrador local, podemos habilitá-lo no modo de segurança por uma GPO em que ative o mesmo temporariamente ou utilizar grupos restritos para este fim);

• Não acessar estações não confiáveis com usuários que sejam administradores de empresa, domínio, etc;

• Usar o mínimo privilégio possível aos usuários do AD (Ou seja, o usuário só deve ter permissão ao que ele irá fazer. Não dando nenhuma permissão a mais);

• Reduzir os usuários dos Grupos Administradores do domínio, empresa, etc do seu AD;

• Fazer a delegação de poderes administrativos. (Delegar poderes em relação a tarefa específica. Por exemplo: usuários que trabalham necessitando instalar impressoras em rede, atribua ao grupo Operadores de impressão e não um grupo mais elevado);

• Atribuir auditorias importantes (Logon, alterações no AD, pastas..).

Apesar destas falhas não estarem diretamente ligadas ao Active Directory, elas são porta de entrada para o comprometimento do mesmo, uma vez que o invasor se aproveita dessas falhas para se proliferar na estação e depois obter senhas de usuários importantes no AD, tais como: Administradores do domínio, Administradores de empresa e Administradores de esquema.

Usuários estes em que podem comprometer todo seu domínio com alterações inadequadas. Outros usuários bastante vistos pelo invasores são os usuários VIPs. Estes usuários são aqueles que tem acessos importantes como a documentação da empresa e a dados sigilosos que podem consequentemente levar a senha dos usuários administradores do Active Directory.

Há outras importantes recomendações para o seu AD que serão postadas mais para frente. Caso tenha algo a complementar, por favor, deixe seu comentário abaixo!

Este artigo também pode ser visto em: https://diegogouveiace.wordpress.com

Convertendo Windows 2000 com o VMware Converter

Tradução: https://translate.google.com.br

Convertendo uma máquina Windows 2000 tem um monte de ressalvas e problemas quando se passa de físico para virtual (P2V), usando o VMware vCenter Converter Standalone. 

requisitos: 

• VMware Standalone Converter versão 4.0.1 (ver informações adicionais no final)
• Update Rollup 1 para o Windows 2000 SP4 ( KB891861 )
• Windows 2000 ferramentas Sysprep ( Q257813 )
• Um LiveCD Windows ou Linux. Eu recomendo Knoppix (6.4+ - Linux) ou Hiren (Windows). 
  Se você precisar modificar chaves de registro, use Hiren.

Procedimento:

1. Instalar VMware Standalone Converter versão 4.0.1
2. Extraia ferramentas Sysprep e colocá-los em C: \ Documents and Settings \ All Users \ Application Data \ VMware \ VMware vCenter Converter Standalone \ sysprep \ 2k 
   Isso deve ser na mesma máquina que tem VMware Converter, não o servidor Windows 2000. 
   * No Windows 2008, o local é C: \ Users \ All Users \ VMware \ VMware vCenter Converter Standalone \ sysprep \ 2k (! Graças anónimo para a ponta) 
   ou C: \ ProgramData \ VMware \ VMware vCenter Converter Standalone \ sysprep \ 2k (! graças Ben)
3. Quer aplicar o pacote cumulativo de atualizações para o servidor ou extrair o conjunto de actualizações e substituí-lo com as SCSIPORT.SYS arquivo em C: \ WINNT \ system32 \ drivers. Aplicando a atualização é recomendada se o sistema é estável.
4. Se você estiver usando um IP estático no servidor Windows 2000, consulte este artigo da Base de Conhecimento .
5. Execute o Converter e implantar o agente. Se você for solicitado para reiniciar, reinicie, em seguida, iniciar o serviço VMware Converter manualmente antes de executar o conversor novamente, caso contrário ele vai lhe pedir para implantar o agente novamente.
6. Na Etapa 3: Veja Opções / Editar, clique no painel de dispositivos e alterar o controlador de disco para BusLogic SCSI.
7. Manter o número de processadores como está, porque se você alterá-lo, Windows 2000 não irá dar auto-detectar novos CPUs e você precisa atualizar a camada de abstração de hardware (HAL) sobre ele manualmente. Veja KB234558 e KB249694 para obter mais detalhes.
8. No painel Redes, desmarque a opção de se conectar a alimentação.
9. No painel Opções avançadas, não selecione as opções para desligar a fonte e selecione a opção para ligar o alvo (VM). Não instalar ferramentas VMware. 
   Não selecione "configurar as preferências dos hóspedes para a máquina virtual"

Com isso, você deve ser definido para converter essa máquina. Após a conversão for concluída, a VM vai começar, instalar ferramentas de VMware, em seguida, reinicie. Depois que ele vem até você deve aplicar as configurações de rede adequadas, em seguida, desligar e permitir que o NIC para ligar ao ligar.

Problemas e Soluções:

• "Disco de leitura de erro" ao iniciar a máquina virtual. 
  Isso acontece porque você selecionou o controlador de disco como "Preserve Fonte" ou "IDE" - você deve selecionar "SCSI" - depois de fazer isso, você vai precisar para reconverter a máquina.
• "Kmode_Exception_Not_Handled" tela azul da morte (BSOD) durante a inicialização. 
  Isso acontece porque o Windows 2000 está usando o driver SCSI de idade (SCSIPORT.SYS). 
  Você deve inicializar em um LiveCD e substituir o arquivo no local mencionado acima. 
  Isto aconteceu-me mesmo depois de eu copiou os SCSIPORT.SYS para a máquina de destino antes de converter.
• Depois de instalar o agente Converter, você enfrenta problemas e reiniciar o servidor Windows 2000, em seguida, ao executar o conversor novamente, ele pede-lhe para re-implantar o agente. 
  Isso acontece porque quando o sistema Windows 2000 surge novamente, o serviço do agente Converter não é iniciado novamente. 
  Abra o console de serviços (services.msc na pista) e clique com o botão direito VMware Converter em seguida, escolha Iniciar. Depois que o serviço é iniciado, executar VMware Converter e ele deve se conectar.
• Não é possível comunicar ao agente. 
  O tráfego de rede provavelmente está bloqueada por firewalls que estão na máquina Converter, a máquina de destino Windows 2000 ou no meio. Verifique se os firewalls estão desativados ou porta 9089 é permitido passar.
• "Dispositivo de arranque inacessível" tela azul da morte (BSOD) durante a inicialização. 
  Isso acontece devido a algum erro de configuração dos motoristas no Registro. 
  Para corrigir isso, execute o programa Converter novamente e fazer uma reconfiguração máquina só (não reconverter). Deixá-lo instalar o VMware Tools, selecione "máquina virtual de destino Reconfigurar" e não selecionar "Configurar preferências dos hóspedes para a máquina virtual" 
  Se isso não resolver o seu problema, leia esta lista de discussão .

Usando O LiveCD Linux:

Se você é novo no Linux, então aqui estão alguns passos para ajudá-lo a substituir arquivos em máquinas virtuais.

1. Inicializar a máquina virtual a partir do LiveCD, por qualquer anexando o arquivo ISO do armazenamento de dados, a sua máquina, ou queimar a ISO em um CD (como uma imagem!) E inicializando-lo da sua unidade de CD.
2. No prompt de inicialização do Knoppix, apenas pressione Enter para inicializar a interface gráfica.
3. Agora precisamos anexar rígido da VM para o sistema Linux: abra um shell de root / terminal.
4. Tipo: fdisk -l 
   Isto irá listar todos os discos em sua VM. Identifique o seu disco rígido do sistema operacional (por capacidade, se possível). Se não for possível, então prosseguir com os próximos passos até encontrar a sua partição desejada por olhar para o seu conteúdo. 
   Você vai ver coisas como: / dev / sda, / dev / sda1, / dev / sda2, ... etc. sda é o seu primeiro disco rígido. sdb é o seu segundo disco rígido. sda1 é a primeira partição no seu primeiro disco rígido.
5. Tipo: mkdir / mnt / os
6. Se o seu sistema operacional (OS) é instalado no primeiro disco rígido, primeira partição, em seguida, digite: mount / dev / sda1 / mnt / os
7. Agora você pode abrir um gerenciador de arquivos na interface gráfica e ir para este diretório: / mnt / os - você verá o conteúdo da partição. 
   Se isso não é sua partição desejado, passe para a etapa 10, em seguida, tentar montar outra partição. 
   
   
   Nota: Certifique-se de montar uma partição e não um disco! 
   mount / dev / sda1 é correto. mount / dev / sda não é.
8. Para copiar um arquivo através da rede a partir de um compartilhamento do Windows em outra máquina, abrir um gerenciador de arquivos e no tipo de guia endereço: smb: // ip 
   Exemplo: smb: //192.168.0.1, onde o IP é da máquina que você deseja acessar através da rede para copiar um arquivo de.
9. Botão direito do mouse e copiar o arquivo, em seguida, ir para / mnt / os e colá-lo lá.
10. Você está quase pronto. Agora você só precisa desmontar a partição, então feche a janela do gerenciador de arquivos que abre / mnt / os e, em seguida, no tipo de shell de root: umount / mnt / os
11. Reinicie o VM e Solte o CD / ISO.

Informação adicional:

• Knoppix é como qualquer sistema * nix: maiúsculas e minúsculas quando se trata de nomes de arquivos. Então você pode ter que apagar o arquivo original manualmente copie o novo arquivo .SYS, devido à diferença no caso de letra.
• As ferramentas Sysprep será usado pelo conversor VMware para preparar uma nova cópia do Windows. É requerido para o processo de clonagem.
• Suporte para Windows 2000 tiver caído no VMware Converter versão 4.3.
• VMware Converter Standalone é gratuito. VMware exige que você se registrar para poder fazer o download, mas os seus servidores são lentos (pelo menos na minha experiência). Eu tenho a minha cópia do 4shared, então basta procurá-lo e verificar o MD5 checksum. 
  Do Windows: VMware-converter-4.0.1-161434.exe - 35f22a3b40b114d70cdbda2d5056c10f 
  Linux: VMware-converter-4.0.1-161434.tar.gz - 90ce68a9f75af91aed9119d419a98b3c
• Seleção LiveCD: você pode escolher qualquer coisa que funciona para você, desde que ele tem drivers de disco SCSI, caso contrário você não será capaz de ver os discos da VM (que é por isso recebendo Damn Small Linux foi uma perda de tempo ...) e pode ler e escrever para o sistema de arquivos NTFS.

Fonte: http://mbhtech.blogspot.com.br

Recuperando data do ÚLTIMO ACESSO dos arquivos

Acesse o registro do Windows e altere o valor da chave abaixo para 0.

Limites FSRM relatório de armazenamento - Windows Server 2012

Configurando configurações de relatório de limite usando o PowerShell

Arquivo do Windows Server Storage Resource Manager vem com um conjunto de armazenamento de funções que permitem que um usuário para gerar uma variedade de relatórios valiosos sobre as partes de arquivos de relatórios. Os valores padrão para limites de relatório, por exemplo, arquivos max / relatório, são pré-configurados para provar apenas valores de tamanho. Infelizmente, Antes Server 2012 R2, File limites relatório de armazenamento não eram acessíveis a partir da interface do usuário FRSM. Com nenhuma interface do usuário para gerenciá-los no FSRM, o usuário pode ser muito confuso com a saída de relatórios de armazenamento quando eles não estão cientes da existência de limites de relatórios. Pior ainda, tem sido difícil encontrar documentação explicando quais são esses limites e como repor-los sozinho. Assim, este artigo está sendo fornecida para melhorar essa situação.

O objetivo deste post é para lhe fornecer a informação que você precisa:

1. Estar ciente dos vários limites de relatórios padrão dentro do Reporting System FRSM como do Windows Server versão 2012.
2. Aprenda a configurar facilmente esses limites usando o Windows PowerShell para valores que lhe permitirá obter as informações que você precisa.

O que não está coberto: Este post não vai

1. Ensiná-lo a instalar ou usar FSRM Relatórios
2. Ensiná-lo a escrever scripts do PowerShell

Com isso, vamos começar. Na próxima seção vou definir as expectativas com você sobre o que você precisa ter feito antes de usar as instruções e outros pré-requisitos, como permissões e configurações necessárias. 

---

 PREPARADOS E PREMISSAS

Neste momento eu estou supondo que você tenha instalado o papel Resource File Storage Manager para a instância do Windows Server 2012 e todas as atualizações de roll-up publicados atualmente foram instalados.

Pressupostos adicionais antes de começar incluem:

1. Você está plenamente versado na operação do papel FSRM no Windows Server 2012
2. Você entende como executar comandos PowerShell
3. Você está conectado ao servidor com privilégios de administrador local

 FSRM LIMITES notificação definidos

A tabela a seguir define o limite de notificação suportado constantes FSRM usa para restringir a saída de relatório para fins de mitigação de impactos de desempenho a partir excessivamente grandes conjuntos de dados:

O usuário é livre para definir qualquer uma dessas constantes para atender suas necessidades de saída de relatório.

Os meios de fazê-lo é consistente para todos e vai ser explicado no Passo a Passo seção.

 RELATÓRIOS LIMITE CONSTANTE DEFAULT VALUES

Dependendo da sua versão do Windows Server, cada uma das constantes limite relatório descritos acima vem com um valor codificado padrão.

Os valores atuais sempre será exibido na sua janela PowerShell quando você define qualquer constante para um novo valor.

NOTA: O Windows Server 2012 R2 permite a configuração desses valores no quadro do diálogo relatório de armazenamento Propriedades tarefa de FSRM, com base no tipo de relatório selecionado, clicando no botão "Editar Parâmetros" como mostrado abaixo:

 INSTRUÇÕES PASSO A PASSO

As etapas para alterar o valor atual de uma constante Limite Relatório FSRM são bastante simples e fácil.

Depois de ter identificado a constante especial que você deseja mudar, ele será usado no comando a seguir, substituindo o parâmetro <>.

Set-FsrmSetting - <ConstantName> <NewValue> -PassThru

Para executar este comando com o seu parâmetro, vou usar o "MaxFilesPerPropertyValue" como um exemplo, e definir o novo valor para 1 milhão.

As etapas para fazer isso são as seguintes:

1) Vá para o ecrã inicial

2) Localize o ícone do PowerShell e botão direito do mouse-lo. Na barra de status do Windows na parte inferior da tela, escolha a opção "Executar como Administrador", como mostrado na figura abaixo:

3) Quando o PowerShell comando da janela aberta, digite o seguinte comando:

Set-FsrmSetting -ReportLimitMaxFilesPerPropertyValue 1000000 -PassThru

Isto irá permitir um relatório para conter até 1 milhão de ficheiros para cada valor da propriedade relatado.

Se você tem acesso a este comando com o seu login atual, o comando será executado e fornecer um resumo das atuais Valores FSRM de parâmetros como mostrado abaixo.

Se você não tem acesso ao comando, você verá a mensagem "Acesso negado"

NOTA: Se você receber uma mensagem de erro indicando que o comando PowerShell que você está tentando executar não está assinado digitalmente ou a execução de scripts está desativado, consulte o PS comando Ajuda set-executionpolicy para obter informações sobre como resolver o problema.

 Os nomes dos parâmetros correspondentes a cada relatório Limitar CONSTANTE

Observe o nome do parâmetro no comando é uma variação do nome constante real, não o próprio nome.

O nome constante é definida na API do FSRM que está sendo chamado pelo cmdlet PowerShell.

Assim, em vez de usar "FsrmReportLimit_MaxFilesPerPropertyValue", usamos "ReportLimitMaxFilesPerPropertyValue".

Nota: Você deve usar a mesma convenção para as outras constantes ao especificar o nome do parâmetro associado no comando.

Eu incluí uma tabela com as traduções nome de parâmetro para sua conveniência abaixo:

Relatórios limite de nome constante	Nome parâmetro
FsrmReportLimit_MaxFiles	ReportLimitMaxFile
FsrmReportLimit_MaxFileGroups	ReportLimitMaxFileGroup
FsrmReportLimit_MaxOwners	ReportLimitMaxOwner
FsrmReportLimit_MaxFilesPerFileGroup	ReportLimitMaxFilesPerFileGroup
FsrmReportLimit_MaxFilesPerOwner	ReportLimitMaxFilesPerOwner
FsrmReportLimit_MaxFilesPerDuplGroup	ReportLimitMaxFilesPerDuplicateGroup
FsrmReportLimit_MaxDuplicateGroups	ReportLimitMaxDuplicateGroup
FsrmReportLimit_MaxQuotas	ReportLimitMaxQuota
FsrmReportLimit_MaxFileScreenEvents	ReportLimitMaxFilesScreenEvent
FsrmReportLimit_MaxPropertyValues	ReportLimitMaxPropertyValue
FsrmReportLimit_MaxFilesPerPropertyValue	ReportLimitMaxFilesPerPropertyValue

4) Substitua o nome do parâmetro no comando exemplo com o que você deseja mudar, e fornecer um novo valor no lugar do meu, e você tem isso.

Emitir o novo comando na janela de comando do PowerShell para coincidir com a estrutura:

Set-FsrmSetting - <ConstantName> <NewValue> -PassThru

RESUMO

Depois de ter executado um comando com sucesso, você deve ver um novo resumo de FSRM ativa Constantes exibidos com o seu novo valor associado ao parâmetro especificado relatórios. Se você tem uma mensagem de erro em vez disso, é provável que você misspelled alguma parte do comando ou parâmetros, fornecido um valor inválido, ou não tem os privilégios apropriados para executar comandos FSRM.

Para mais informações sobre os comandos FSRM PowerShell, visite este TechNet Link:

http://technet.microsoft.com/en-us/library/jj900651.aspx

Você pode rever a lista completa dos parâmetros utilizados no cmdlet PowerShell "Set-FsrmSetting" neste link TechNet:

http://technet.microsoft.com/en-us/library/jj900644.aspx