We have recently migrated a single server exchange 2007 organisation out to a hosted exchange platform and everyone is working fine against the new platform.
The question I have is a simple one really.
Should I go through the process of properly uninstalling the exchange organisation from the server that it is on or should I just turn the server off. Presently the box is still on, albeit with all of the exchange services stopped.
I read that uninstalling the exchange organisation won't remove the objects/attributes that are added to the AD so is there any benefit of removing the organisation opposed to just turning off the server. Will there be any issues down the line with AD if I don't uninstall, and anything to be aware of if I did uninstall.
I would recommend turning the box off and take a backup of the hdd if later issues would occur (which propably won't because, as you say, all services are stopped). After these steps, you can format or do whatever you want to it.
Related
I have installed a SCCM system. My problem now is that I don't know how to integrate clients that are on the same network like the SCCM.
I have already created a location in the SCCM-Console and i have to integrate application software into the SCCM.
The Testclient already has a Windows 7 installed.
My question: How do I connect a client with the SCCM?
It kind of seems like you are potentially asking a few different things here so I will give an answer to what I think you are asking and hopefully that helps
1. To add computers to sccm so they show up in your management console, you can either do it manually or via discovery. You can configure discovery in the administration tab. Normally you will want to discover computers from your AD setup.
2. To install the sccm client on the computers, you can either do it manually by running the software on the PC. Alternatively you can push out the client to computer by right clicking them and pushing out the client there.
3.To add software to sccm you can go to the software library tab and create either packages or applications.
Hope this helps.
You need to setup boundaries and boundary groups within SCCM based on subnet or AD sites.
Take a look at this example: http://shabaztech.com/sccm-2012-r2-client-installation/
If you have discovery turned on, you should be able to right-click a computer object within the SCCM console and install the client, assuming you have the proper accounts and firewall rules setup.
First off, I read all other Questions, that relate to this, I did an extensive google search on this topic and could not get a working answer.
I installed the Community Version of Visual Studio 2015 in mid November and been using it since then. After finishing my project, I went back to pen and paper for new formulas and noe came back to implement all those neat things.
Now it says, that my trial license has expired and should be renewed. I already read, I should use my MicrosoftAccount to do that, and proceeded by doing that.
Now this happened
It says, I should check firewall and prxoy settings and I read about contactiong the administrator. So that, what I did, but he says, there is no proxy, no block by firewall or anything else.
When running VS as administrator (after entering my credentials) I can create new projects and debug existing ones, so no problem there. However I can not use the program as normal user.
I read somewhere here to try repair it via systemcontrol, but that did not work either.
Does anyone has a solution?
In addition: There is also no "Enter License Key here" field, so that is also not an option.
(several Days later)
Halleluja, I found the answer! After digging through some Microsoft Help-Forums, I came upon this Thread, that not only perfectly describes my problem, but also gives a solution. So dear visitor from the future, who googled the problem and came upen this Stackoverflow Question: Follow the link above!
So, after sniffing packets harder than a drug addict, trying to find a difference in TLS exchanges between my computer and VS licensing server when using a domain account and when a using local account, and noticing no difference, I recalled why I had pushed this hypothesis to the side: our network supports TLS 1.2 perfectly well, as I can connect to TLS 1.2-only remote hosts without any issue.
This means the issue lies elsewhere, and is caused by Visual Studio treating domain accounts and local accounts differently when trying to renew licensing information.
The good news is I've found why and how to fix it.
I recalled that earlier this year, when we upgraded our commercial department from Windows 7 to Windows 10, they all encountered issues while trying to configure their mail accounts on Microsoft Outlook: an unknown error 0x8004011c. If you search around for it you'll quickly find that this only happens when using domain accounts and not when using local accounts (sounds familiar, heh?). The fix to bypass this issue is to set a specific Windows cryptography-related registry key.
When digging a little deeper, you can find that this fix is related to KB 3000850 (which I sadly cannot link to due to my account not being verified) and is actually described in the "Known issues" section, as well as in Samba-related documentation ("Required Settings for Samba NT4 Domains").
In short: Windows 8.1+ clients (with KB3000850) joined to an NT-Style domain are not able to use Windows Credential Manager. This doesn't occur when not using a NT-Style domain. The fix seems to globally authorize using Windows Credential Manager whatever the domain context.
So, to wrap it up, if:
You have a NT-Style domain (such as when using a Samba domain controller)
You have Windows 8.1 or later
vYou encounter issues when renewing your Visual Studio license
Then, set the following registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001
This solved the issue on our domain, for all machines and accounts tested.
As to why Visual Studio 2015 needs to use Windows Credential Manager and not Visual Studio 2013, someone from Microsoft will have to chime in there to explain because I have no clue.
You are using a very old Samba server that uses unsupported features. NT4 came out in 1995. Active Directory didn't exist back then. A lot has changed in the last 20 years, including strengthening security and gradually removing older, less secure features like LanMan and NT4 domains.
Instead of weakening security, you should follow the advice posted in the page you linked, Required Settings for Samba NT4 Domains:
Microsoft discontinued the official support for NT4 domains in their Windows operating systems. ... Anyway, consider migrating to a Samba Active Directory (AD) to avoid problems if a future update from Microsoft disables or removes the unsupported NT4 features.
We've transitioning from Rackspace dedicated boxes to a completely cloud Azure environment. Production servers and development and as an MS shop we're going to be using Visual Studio Team Services. As an MS ISV partner we have a bunch of MSDN seats so our developers are all going to have an MSDN w/ VS Premium account which we'll use with Team Services/TFS. We're replicating our production web server on a virtual machine but after some refactoring will eventually move to an Azure website.
My question is about when users leave the company. Right now we have everyone log into a development server using RDP. They develop on that server. When someone is gone we shut their access off to that server.
With Team Services when the user opens up a project do they automatically get the entire project downloaded to their local development environment/machine? If someone leaves the company is there a process using VSO that secures that code and removes it from them or makes it inaccessible? Any way to lock it down when we need to? I can't seem to find a procedure to do this.
To add or remove someone from the account, go to the Users hub on the home page for your account. If you remove a user from it, that user will no longer be able to access your account.
When users connect to your account, they'll need to take some action to get source code. That would be cloning in the case of using Git or creating a workspace and running get for TFVC.
If the user has source code, for example, on a machine, there is no way to remotely remove it. They won't be able to get updates, etc., but there's nothing running on the computer that would be able to erase the code the user has already obtained.
All source code sharing i know allow zipping up or browsing the local repository. Including VS Team Services.
Daniel Mann is correct . Developing on shared servers via RDP is terrible for productivity due to development being graphics and disk intensive, often requiring admin rights and reboots / crashes, debugging triggers system interrupts, out of memory loops are fun on a shared machine ie they stuff everybody else around. (Even with RDP you can copy and paste or map a network drive locally or upload to the net )
If your doing critical stuff the ONLY thing that really works is physically bring them in to non internet connected machine /network with USB disabled. However these mechanisms especially denying internet will half productivity.
This is why most organizations rely on legal contracts. On a 2M project is it worth making it a 4M project? There are cases where this is required normally around national security /CIA / Defence but not for IP, there are better / trickier ways.
Pretty much all binaries are reverse engineer-able with little effort if you really want to. obfuscation does very little.
Recently our Development user group (Windows) has started showing with a Red Cross in Team Explorer and we cannot expand it anymore.
I have tried removing and re-adding the group but to no avail.
Does anyone know why it would display like this?
We are using TFS 2010 with VS2010 SP1 and August's Power Toys.!
BTW, "Technical Testing Team" is another Windows Domain User Group, just like Development and that works OK.
In general, the red crosses on particular services are caused either by that service being unavailable or by permissions issues...
Are you still able to perform actions that require admin permissions? Does this apply to a single project or all?
How are you defining your developers? A windows domain group? If so, is the TFS server able to see the DC?
I'd suggest you try installing Team Explorer on the TFS server and running it when logged on as yourself - see if you have the same problem. If not, it may be network or firewall problems between your dev machine and the server. At least it would narrow the problem down.
Edit 1:
Do reports work properly? (Specifically, do the graphs show up in reports)?
What auth are you using? Kerberos?
What account is TFS running as? What permissions (if any) does that account have on the network?
Can you see the security information you'd expect in the TFS_Configuration database? (Try tbl_SecurityAccessControlEntry) [Usual "Change nothing, do it at your own risk" disclaimer]
Edit 2:
As per the install docs, the TFS service should be running under its own account (IIRC they suggest Domain\TFS.Service). Check the permissions on the windows services on the TFS Server and see who they're running as. Makes sure the permissions for that user are correct as per the installation instructions
NTLM can cause problems as it doesn't allow credentials to be delegated/relayed the way Kerberos does (and has some picky setup requirements) - but that's obviously not why it's broken all of a sudden (and that usually manifests as graphs not displaying in reports).
WRT: the SecurityAccessControlEntry table, I was more interested in making sure there were entries and that it could be read properly than the contents.
I assume you've tried deleting/recreating groups - If not, give it a shot (deleting the domain group may be an issue with other services but try using a different (new) group and removing the old one from TFS entirely)
I have to admit I'm running out of ideas after that. If it were me, I'd try a clean install on a new server/VM and either point the new install at the old data store [multiple server setup] or export/import projects [single server setup].
For Multiple server setups, this would determine if it's a TFS installation issue/data corruption. For single-server, there's a good chance this would just clean up the problem. You could, of course, also ex/import on multi-server too if it does turn out to be a data thing.
You may want to hang on to see if someone has a less drastic solution.
Looking in the General tab of the VS Output windows there is a message:
Skipping loading group Development into Team Members because it has 102 members.
Looks like VS has a limit on here.
What, if any, extensions can be run on Microsoft Exchange that then become visible to Outlook users?
Basically I'm wondering how to integrate at the Exchange layer, avoiding the task of having to install a plug-in or whatever for each Outlook user.
It really depends upon what you are trying to do.
If you are writing an Outlook add in that needs to run on the client PC and directly interface with Outlook at run time, you need to install on that PC. It needs to be there weather the Exchange server is able to be connected to or not.
If you can make your application do its magic completely at the server side, then yes it is possible. There are many ways to implement add-ins on the Exchange server side.
Maybe look into packaging your add-in as a MSI file that is a required application and have the Windows server auto install it if it is not there.