2016年4月18日月曜日

IIS 7.5 FTPで550 Access Denied

1.FTPにログインするユーザーに該当フォルダの書き込み権限を与える
2.FTPの管理画面、FTPの承認規則で書き込みにチェックを入れる

2015年12月24日木曜日

Windows Mobile デバイスセンターとリモートデスクトップ

USB接続したWindows CEデバイスをリモートデスクトップを
使用した際にWMDCに認識させるには、
デバイスを接続したPCにログインし、
その状態でリモートデスクトップで接続する。

デバイスを接続しているPCをログオフ状態にし
リモートデスクトップで接続して、Active Syncを実行しても
WMDCが認識せず、接続できなかった。

2015年11月27日金曜日

XCOPYの失敗

長いファイル名(256文字以上)を含んだフォルダーをXCOPYでコピーしたところ、コピーされずに終了した。

タスクスケジューラで起動すると、前回の結果が0x04となっていた。

【失敗したXCOPY】
XCOPY /Y /E /D /C /R 元フォルダー 先フォルダー

ROBOCOPYで対応した。

【使用したROBOCOPY】
ROBOCOPY /E /XO /IS /XJ /XJD 元フォルダー 先フォルダー

2015年11月1日日曜日

net.tcpでの通信

SvcEditorで操作した。
■netTcpBindingでの接続
    ・web.config
        ・netTcpBindingでバインドを作成する
        ・エンドポイントを追加し
          binding:netTcpBinding
          bindingConfiguration:上で作ったバインド
   
        と設定する。

<?xml version="1.0"?>
<configuration>
    <system.serviceModel>
      <bindings>
        <netTcpBinding>
          <binding name="MyTcpBinding">
            <security mode="Transport" /> ※2
          </binding>
        </netTcpBinding>
      </bindings>
      <behaviors>
        <serviceBehaviors>
          <behavior name="TestBehavior">
            <serviceMetadata httpGetEnabled="true" httpGetUrl="" />
            <serviceDebug includeExceptionDetailInFaults="true" />
          </behavior>
        </serviceBehaviors>
      </behaviors>
      <services>
        <service behaviorConfiguration="TestBehavior" name="TcpServiceTest.TestService">
          <endpoint address="" binding="netTcpBinding" bindingConfiguration="MyTcpBinding"
            contract="TcpServiceTest.ITestService" />
          <endpoint address="mex" binding="mexHttpBinding" bindingConfiguration=""
            contract="IMetadataExchange" /> ※3
          <host>
            <baseAddresses>
              <add baseAddress="net.tcp://server/dev/TcpServiceTest.TestService.svc" />
              <add baseAddress="http://server/dev/TcpServiceTest.TestService.svc" />
            </baseAddresses>
          </host>
        </service>
      </services>
    </system.serviceModel>
 <startup>
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
 </startup>
</configuration>


    ・クライアント側のexe.config
        ・netTcpBindingでバインドを作成する
        ・エンドポイントを追加し
          binding:netTcpBinding
          bindingConfiguration:上で作ったバインド
   
        と設定する
Visual Studioのサービスの参照を行って作成されたconfigの中身。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors />
        <bindings>
            <netTcpBinding>
                <binding name="MyNetTcpBinding">
                    <security mode="Transport"> ※2
                        <transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
                        <message clientCredentialType="Windows" />
                    </security>
                </binding>
            </netTcpBinding>
        </bindings>
        <client>
            <endpoint address="net.tcp://server/dev/TcpServiceTest.TestService.svc"
                binding="netTcpBinding" bindingConfiguration="MyNetTcpBinding"
                contract="sr.ITestService" name="NetTcpBinding_ITestService">
              <!-- ※1
                <identity>
                    <userPrincipalName value="username@domain" />
                </identity>
              -->
            </endpoint>
        </client>
    </system.serviceModel>
</configuration>

※1
userPrincipalNameの意味がわからない。
指定するとSecurityNegotiationExceptionが発生する。
これにドメインに存在するユーザーIDを入れると上記Exception。
削除または全然関係ない文字列「aaa」とか「adfdfgh@domain」とか
適当な値を入れると正常に通信できる。
謎の設定。

※2
Messageにすると
「通信オブジェクト System.ServiceModel.Channels.ServiceChannel は、状態が Faulted であるため通信に使用できません。」
となってしまう。(調査中)

※3
メタデータの公開が必要なければ削除可

2015年10月26日月曜日

SQL Serverのログイン名とユーザー名

OracleばっかりやっててSQL Serverのログインでハマったので、
SQL Serverのログイン名とユーザー名について記述。

・ユーザー名とログイン名は違う
・ログインはインスタンス単位でユニーク
・ログインはログインするためだけのもの
・ログインはインスタンスへのアクセス権限を保持
・ユーザーはデータベース単位でユニーク
・ユーザーはログインと関連付ける(ALER LOGIN)
・ユーザーはデータベースへのアクセス権限を保持

なので、ログインとユーザーの関連は1対Nとなる。
と思ったけど、1対Nになるのは、ユーザーが同じ名称で複数のデータベースに存在する場合。

1つのデータベースに同じログインのユーザーは作成できない。

ログインはSIDでユーザーと関連付けされるため
別インスタンスで同じログインとユーザーで
関連付けていたものを、データベースの復旧等で
別インスタンスに復旧した場合は
ログインとユーザーの関連は外れるので、ALTER LOGINで関連付ける必要がある。