I just created a user in Active Directory. I would like to create an exchange mailbox for this user. Can I just set some of the users properties? Something like this:
DirectoryEntry user = ...Get the user
user.Properties["someProerty"] = "someValue";
user.CommitChanges();
Where someProperty and someValue are what is needed to create a mailbox?
Is there documentation on how to do this? Could you tell me what properties need set?
No, an exchange mailbox is more than just properties on an LDAP entry. You'll actually need to work with Exchange directly to accomplish this. If you are using Exchange 2007+ you can use the New-Mailbox PowerShell commandlet.
In one of my previous jobs, I installed the Exchange Management Tools on my web server and automated creating a PowerShell runtime environment to execute the necessary commandlets. Once you execute the right commands the attributes (such as mailbox, email, etc.) will be added by Exchange.
You can create a PowerShell runtime environment by creating a runspace.
http://support.microsoft.com/kb/313114 perhaps.
There is tons of documentation on these things, try google ;)
For 2007 exchange try this http://social.technet.microsoft.com/Forums/en-US/exchangesvrdevelopment/thread/4cd5ea2e-5967-42f2-a503-f1e031a1b393/
No You have to use powershell cmdlet to change some properties of mailBox .For Example You can not change Alias Name with the help of Active Directory Cmdlets.I am also new and this is just my experience.hope this will be helpfull to you.
Related
Using ADSI I can query the members of the local Administrator group on a given computer by doing (for example in PowerShell) :
([ADSI]"WinNT://computer-name/Administrators,Group").Invoke("members")
To do this, as far as I can tell, the user running the PowerShell script requires Administrator privileges on the target machine - that is, the user needs to be directly on indirectly in the local administrator group of computer-name (eg. by being a member of "Domain Admins").
This surprised me because a non-administrator account who can login to computer-name (eg. a user that's part of "Domain Users" and nothing else) can open the local users & groups application, and view the members of the local administrator group. No specific rights are required when doing it manually, yet ADSI seems to require it.
So my questions are:
Is it correct that using ADSI you need Administrator rights to access this information, or am I doing something wrong?
Is there a different approach to programmatically obtain this information, which requires less privileges than an Administrator account ? (If there are solutions that are not available in PowerShell that's fine, my targets are C#/.NET Core )
Please note I want to run this remotely on other workstations - not just on the local workstation.
ADSI is built on top of WMI. By default, only the local Administrators group is allowed to make remote WMI calls and read a computers local directory data.
You can change the permissions on the OS by going into Computer Management (local) -> Services and Applications -> WMI Control. Right click on WMI Control and choose Properties.
I've only experimented with allowing all reads, which you can set on the root folder. I did some research and you may be able to restrict this to just LDAP. On the Security tab drill down to Root -> directory -> LDAP. You'll want to adjust permissions on the LDAP entry (or maybe more?). The key permission is Remote Enable.
Update
To query WMI directly from PowerShell.
Remote WMI over PowerShell: https://learn.microsoft.com/en-us/windows/win32/wmisdk/connecting-to-wmi-on-a-remote-computer.
Custom PowerShell method for listing remote group membership through WMI: https://gallery.technet.microsoft.com/scriptcenter/List-local-group-members-c25dbcc4
I think your ADSI approach should work, at least when executed locally.
I used a c# snippet I grabbed from this SO answer: https://stackoverflow.com/a/8192062/3374994.
To test whether it could run from regular user permissions, I used
Runas /user:regularuser GetLocalUsers.exe.
I believe this shows that an ADSI approach would not necessarily require elevated privileges.
However, was your intention to run the code remotely?
var path = string.Format("WinNT://{0},computer", Environment.MachineName);
using (var computerEntry = new DirectoryEntry(path))
{
var userNames = from DirectoryEntry childEntry in computerEntry.Children
where childEntry.SchemaClassName == "User"
select childEntry.Name;
foreach (var name in userNames)
Console.WriteLine(name);
}
So I have queried Active Directory before and I know about disabling accounts and creating user accounts. However, I need to be able to kind of create and reserve computer names. I am writing a .net ASP program for it. Is this even possible?
Thanks!
example of how to add computer
DirectoryEntry de01 = new DirectoryEntry("LDAP://CN=Computers,DC=fabrikam,DC=com");
DirectoryEntry newComputer = de01.Children.Add("CN=New Computer", "computer");
newComputer.CommitChanges();
I’m converting an existing piece of code using Redemption (an MS Exchange library) to operate under a service account. The issue I’m having is that I’m unable to look up mail folders as I previously was.
The first hurdle in moving to a service account was overcome by switching
_rdoSession.Logon() // <- Which uses the account’s MAPI profile, and throws an exception under a service account
To:
_rdoSession.LogonExchangeMailbox("", "mailserver.example.com");
The problem comes with trying to access specific folders. Previously I was able to use:
_session.GetFolderFromPath("\\\\Mailbox - Example shared mailbox\\Inbox\\FolderOne");
_session.GetFolderFromPath("\\\\Mailbox - Example shared mailbox\\Inbox\\FolderTwo");
Under a service account, I can’t address shared mail accounts with that same syntax, as I get the error:
Could not open store "Mailbox – Example shared mailbox": Error in IMAPITable.FindRow: MAPI_E_NOT_FOUND
Some Googling has shown the beginning step is to use:
_session.Stores.GetSharedMailbox("Example shared mailbox ")
I've verified this returns the correct shared mailbox object.
However - from there, there are no search methods. I can try my luck with building new code to navigate the folder structure from the .RootFolder property, but this seems like a hack.
How should I be accessing specific folders in a shared mailbox, run under a service account in Redemption?
You can use either
store = _session.Stores.GetSharedMailbox("Example shared mailbox ");
folder = store.IPMRootFolder.Folders.Item("Inbox").Folders.Item("FolderTwo");
or
store = _session.Stores.GetSharedMailbox("Example shared mailbox ");
folder = store.GetDefaultFolder(olFolderInbox).Folders.Item("FolderTwo");
I'm trying to debug a webpart installed on a client's SharePoint instance. I wanted a quick and easy logging feature, so I thought of writing messages to a text file in the temp directory. SharePoint doesn't seem to like it, so what are my options?
IF you are writing to the temp directory, you will need to give the file (if it exists) or the directory rights for the IIS Application pool that the SharePoint IIS application is running under.
There are few ways of custom logging in sharepoint -
Use SPDiagnosticsService - You may write to the ULS via SPDiagnosticsService class.
Utilize diagnostics.asmx web service -
SharePointDiagnostics SharePointDiagnosticsObject = new SharePointDiagnostics();
SharePointDiagnosticsObject.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
string Response = SharePointDiagnosticsObject.SendClientScriptErrorReport(message, file, line, client, stack, team, originalFile);
For more details on usage of diagnostics.asmx refer the following link -
https://vivekkumar11432.wordpress.com/2016/09/23/how-to-do-logging-in-uls-from-csom-in-c/
For more details on logging refer the following link -
http://www.codeproject.com/Articles/620996/Five-suggestions-to-implement-a-better-logging-in
Don't use
Microsoft.Office.Server.Diagnostics.PortalLog.LogString("Message");
According to Microsoft documentation - LogString is reserved for internal use and is not intended to be used directly from your code.
I would guess that this is a permissions issue that SharePoint is blocking you on (and probably not telling you that it is). When you try to write to a text file on the server, you need to have elevated permissions in order to do it. You can accomplish this using SPSecurity.RunWithElevatedPrivileges. Something like the following, if you want just a simple, small-code solution.
SPSecurity.RunWithElevatedPrivileges(delegate() {
using (StreamWriter sw = new StreamWriter(#"C:\log.txt"))
{
//log information here
}
});
Try a logging framework like log4net, or write a small logging framework writing into an external database, you could also use lists to log if you want to stay inside sharepoint
I am trying to find a way to get a list of Windows sessions? I need the same information as the one displayed in the Task Manager on the User tab. I need to know if the user is active or not and if s/he is logged on in the Remote Desktop session.
Any idea on how to do that with C# / Windows XP Pro?
As a starting point you can get a list of users logged on by running the command
qwinsta
From the command prompt.
This will give output like
C:\WINDOWS\system32>qwinsta
SESSIONNAME USERNAME ID STATE TYPE DEVICE
>console me 0 Active wdcon
rdp-tcp 65536 Listen rdpwd
and will list any remote sessions.
Use LsaEnumerateLogonSessions via P/Invoke. You'll also need LsaFreeReturnBuffer to cleanup after enumerating.
I believe you'll need to use P/Invoke to retrieve this information.
The relevant APIs are documented in this MSDN page.
Another way is to use the Logonsessions utility from Sysinternals:
http://technet.microsoft.com/en-us/sysinternals/bb896769.aspx
You do not need to use Pinvoke. WMI does it, and well: "select Name, SessionId from Win32_Process" in the root\cimv2 namespace. And, it can be called from a remote machine. Simpler. Add in a where clause in the select to fine tune what you get back.